Using maildir (the current standard for mail storage) with any kind of remote file system is not the best environment to have. Maildir stores every email into a separate file and then uses rename() for every flag change. Marking 1000 messages as "Seen/Unseen" or adding a flag or moving to Trash means 1000 rename() calls in the file system. Multiply that with thousands of users also logged in to the system and doing their own things - you get many millions of inodes and rename()'s flying around all over. Good luck keeping a consistent copy or not crashing the mail server software as it waits for some queued rename() call over network FS to finish (and expects it to take nanoseconds as this is how long it takes in a local FS) while blocking everything else.

I don't see how storing the mails in a database will improve the situation. You will still have to update 1000s of records when you mark 1000 messages as seen/unseen or move them into the trash. And the DB will then write the changes to a filesystem.

One of Maildir's design goals was to make it safer to use on networked file systems such as NFS (compared to mbox).