The first option would likely be terribly slow. Scanning emails to check for things that have been moved around and client-side-grepping emails would be extreme

The first option would likely be terribly slow. Scanning emails to check for things that have been moved around and client-side-grepping emails would be extremely slow. For this to even work you'd probably want some local cache, which is not trivial to do. Granted, my benchmark here is people like me who have over 100k emails on their account. The second is likely the better thing to do (But likely not in postgres for large-scale, if anything due to the SPOF. Unless someone really enjoys maintaining postgres clusters). However, you still need some IMAP/JMAP somewhere for normal mail client access, and in this case you'd likely have to implement your own translation/access layer. I would probably come up with something that wouldn't have users directly access a database, and instead provide some sort of identity-aware access layer. Basically reimplementing IMAP/JMAP, again.