dbmail isn't as fast as dovecot for a single user, single event. But not
by much. However, it scales *much* better into the 100's and 1000's of
actions.
<$.02>
I came within an eyelash of going live with dbmail, and then pulled back.
This was a year or so ago, I don't remember exactly. The performance I was
getting on very large IMAP folders was just awful.
So I turned on PostgreSQL query logging, and looked at the query it was
throwing at the database to select an IMAP folder. And then I looked at the
schema. I remember being horrified. It was clear that as a pure database
application, dbmail was *a mess*. The schema was just not well designed for
the queries they were actually making, and not even slightly well indexed.
They may have fixed this in the meantime. I did look at the schema for
archiveopteryx, and it looked to me to be much better thought out. I got as
far as compiling archiveopteryx on my OS of choice (OpenBSD, no flames
please) which was not a supported platform. It built, but I didn't go
further, so I don't have any results.
There's a lot of work in dbmail, and the architecture "around" the database
seems to me to be quality stuff. Now if only they've gotten the database
coding up to the same level ...
If a database as a message store cannot give good performance, then why do
it. Asking for good performance on a folder of 65K messages is not asking
for the moon. dbmail broke my heart. This was a while ago, maybe they fixed
it, or maybe I had my database tuned wrong, but I'd encourage anybody using
a database as a message store for an E-mail system to look over the schema
with a fine-tooth comb and evaluate it like you would part of your ERP
system. If the schema is not well designed for a typical IMAP query, run
the other way.
</$.02>
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
