Store message in a database
With huge mail box on IMAP Mdaemon is a bit slow, store mail in a free (of course) db could be a very good features, easier to retrieve a mail (a simple sql command line to search throught thousand message for example). Easier to backup and move (have you try to move the directory users from a server to an other server with 500 gb of mail) , more securised.
I’ve submitted this to be reviewed for future versions.
I would assume as this suggestion was in 2012 (way before SSD were as common as they are now), this suggestion was never implemented (and likely wont be).
Adding an Intel RAID to standard drives gives SSD type speeds, adding SSD shoots it to the sky in speed... so even with mailboxes being big (10Gb or more) the advances in speed since 2012 would be astronomical with a flat file system.
I also agree this is a very bad idea. Please don't do it. While the only (theoretical) advantage of using a DB is the speed, you'll lose all the simplicity and versatillity of simply restore/backup specific messages. It's not worth it. Like others said, speed could be increased with better hardware, like SSD's and better processors.
I think is a bad idea. FS granular recovery is very simple and fast! DB is not the same thing.
please do not do this! If you do, you'll lose the biggest advantage over exchange or similar databased mailservers.
Bad Idea !! At the Moment Backup and Restore is very easy. Also single item restore is very easy. With a database (one or more) it is like MS Exchange. Restoring of singel items is impossible without special software.
Please do not do this !!!
The problem here is not managing how many files a user has in a folder. These problems start with the file system and end with the client. Regardless of DB or Files, you have the same limitations that affect performance. Outlook has know limitations that it will suffer from performance issues anytime there are more than 5000 emails in a single folder. This does not improve with exchange which uses a DB. Then you have the file system issues. Windows has folder performance issues over a certain number of files. The clear solution here is file / folder management. Mdaemon has easy to use archiving that can be scheduled to clean this mess up. If a user has more than 5000 files in their inbox, THIS IS THE PROBLEM. There are only a couple of solutions, #1 Don't use Outlook, #2 Move the inbox files into different folders, example Inbox2015. You will see amazing results! I have a script this does this anytime someone complains.
We use EaseUs ToDo backup, its backs up the system really fast (for small files).
Navin Patel commented
Both separate file store and DB file store have their pros and cons. I am using Archive Server for MDaemon, which is using third way of saving Email files.
It manages Emails like Drive:\Year Folder\Month folder\date database file. The index of this date database is maintained in SQL server. This have pros of both file store and DB store, while quick to backup and more secure as the emails stored in individual files are readable using notepad.
I have used few backup solutions and all of them are slow when it comes to backup small kb files in large number.
Can MDaemon email store be managed this way?
I would like to add below... BACKUP
If its a database then it has to be INTERNAL to allow backup / restore like a file system (not SQL or something like this). This means IF you use a database then file backup / restore still works then there is an internal system INSIDE MD that allows looking at this database that inside the MD structure.
It will become problematic and is one reason i am looking at MD for email instead of others that use a database
Dan Lundqvist commented
The big advantage with MD IS the easy handling of mails (including backup)
as all are store as files. PLEASE DO NOT REMOVE THIS!!!
Or at lease have 2 options. Either DB OR Flat files.
DON'T! Please DON'T!!!!
Gonçalo Caeiro commented
Please don't do it.
File based email is great. It eliminates the problem of a complete obscure access to email like Exchange is. One advantage of Mdaemon is that the upgrade process is simple because you don't have to upgrade the BD and data in the BD. Also, if you have a problem on some files you are invalidating the all database. Moreover, I can have have email accounts on separate disks and segregate between SSD and HDD for storage. Try to do that with a DB!
And best of all, for auditing proposes, you can run scripts much more easily. Otherwise you'll starting incurring a 10x increase in developing software to work against a DB and a DB datamodel.
I like the way how MD stores Mails. Sometimes it is not perfect, but I know a lot of problems with databaseoriented mailservers. If i will be forced to use a database, I also can use Exchange. If you implement this, please do this only as an option.
I think that this a principal feature because to buy thirty part for this feature no sense. I think that this feature shoud be develop from Alt-n. I don't ask included in Mdaemon but I feel more sure if it's develop from alt-n
I very like this idea, It will be great if we have the possibility to choose the storage (flat file like today or database)
I think it's not too complicated to do, add a wrapper on read/write message class.
I'm looking for this feature, in this way you can connect some emails with your DMS, easier backup, and faster for searching (fulltext indexing, ...)
Emanuele Aliberti commented
Or, at least, please, keep the message files on the file system, but move all metadata (header, message parts structure/offsets, indexes, references, renditions, ...) in to a database.
le tinevez commented
In fact mdaemon is installed on netapp fas 2020 (vmware 4.1) and we have a lot of hardware disk fault, 4 cpu 8 Gb, but the number of access disk is too much. I ve user with 25 Gb of mail box... I think storage in database should be speeder .
we used to have this problem but upgraded the mail server CPU, memory , and used multiple hard drives, and no more issue.
Peter B commented
We use ssd's and mdaemon flies. Costs a bit more but well worth it.