[Dovecot] Creating an IMAP repo for ~100 users need some advice

[Robin]

On 3/17/2012 12:36 PM, Sven Hartge wrote:
> Storing mails inside SQL? Not supported by dovecot and not very wise,
> IMHO. DBmail does this, but to be honest, I never heard any good
> feedback from admins using that product. From what I have been told, you
> need quite the beefy server to get a decent performance out of DBmail,
> compared to the needs of a "traditional" setup like with dovecot or
> courier-mail, but I digress.

Ugh, I've tried the product.  It works pretty well, until you move more 
than a small handful of users and email hives to it, and you hit some 
hard walls pretty fast with how many inbound emails/second it can handle 
for even burly server configurations.

Those hard walls occur at too low a threshold for me.  The product's 
mailing list is supportive and there are many dedicated DBMail users who 
step in an answer questions, but be prepared for "BUY MORE RAM" as the 
answer to concerns about performance.  When 128GB of RAM is needed for a 
small organisation's email setup to perform well, I am strongly inclined 
to move on to the next product.

Best practices for it seem to revolve around being able to have your 
ENTIRE email + index content resident in RAM.  Well, gosh.  Why didn't I 
think of that before instead of wasting all of this time worrying about 
design and efficiency?

And if you're hoping that it will make text searches "automagically" 
fast, think again.

Timo's FTS_SQUAT blows it out of the water by orders of magnitude, even 
with mailbox sizes of around 300K emails (20GB), let alone something 
like Lucene or Solr.

I understand why it seems like a great idea to store email this way, but 
realise that the bulk of email is NOT structured or inherently relational.

=R=