I've been researching DBMail as an alternative to Cyrus. I stumbled onto this thread. One of the post is pretty interesting, arguing that filesystem mailstores are a better choice than DB mailstores. I was hoping to get a response from developers/users of DBMail... as I thought you would most likely have the "other side of the story".
Keep in mind not my words... but interesting arguments. I'm curious that if they are at all true for people who have DBMail in production. Kevin [webtalk.com thread: http://tinyurl.com/6que4 ] The choice of a monolithic store for mail is a major design error, since it imposes excessive global consistency requirements that make recovery difficult, and corruption likely. File-systems offer fine-grained rather than global consistency: Directories point at files that really exist, files point at blocks that belong to them, data flushed to a file persists after a sync operation (explicit or delayed from the buffer cache). Even if a single file is corrupted, global file-system corruption is rare with mature file-systems (I make no specific public claims about which file-systems are mature on which OS). By separating data and meta-data into different files, and ideally meta-data for each folder into a separate file, a mailstore can support fast meta-data recovery (it is the meta-data that is most likely to become corrupted). File-systems support a rich ecosystem of file manipulation tools, if something goes wrong the mail-store meta-data the administrator can still wrest the underlying content from the mailstore and re-build (portions of) the meta-data, obviating the need for a full data and meta-data recovery (in these days of TB sized stores full recovery can be totally impractical). File-system recovery can be faster than database recovery because it is not necessary to arrive at a globally consistent state. One can recover parts of a file-system, restoring individual mailboxes or messages. I cannot honestly recommend to anyone a mailstore design based on any database, regardless of the technology. -- Viktor.
