competition

[Shuvam Misra]

> Kolab Systems is thinking of such SQL databases for integration
> purposes, where the performance penalty now lies within having to use the
> IMAP protocol to gain access to the underlying metadata (seen status,
> message indexes) in distributed groupware environments where Cyrus
> itself is not the only component that needs access to such information
> (but would still remain authoritative, of course, and would be the only
> component with write access to most tables).
> 
> While not necessarily the best approach, it seems worth exploring.

Yes, this is one of the big reasons why we use RDB backends in many of
our products. The downside is performance, of course. But the upside is
very big when you need it -- ability to keep one instance of important
metadata and allow multiple pieces of software on multiple servers to
access it. Most of the time, this metadata is read-often-update-rarely,
so we don't need huge write performance. But if we have to
synchronise the data across multiple servers and use local files like
SQLite/BerkeleyDB/gdbm, we land up building entire synchronisation layers
just to ship updates around from server to server.

This is not Cyrus-specific -- any metadata which needs sharing across
multiple servers seems to be easier to build with a network-accessible
database, and an RDB is the commonest of them (SQLite being an exception).
Basically, memcached is "better than" BerkeleyDB hashmaps in these
situations.

Shuvam