Choosing a Dovecot Mailbox Storage Format: maildir vs mdbox vs dbox

The decision and its constraints

Every Dovecot deployment eventually forces one storage decision that is painful to undo: the mailbox format in mail_location. The three supported options — maildir, mdbox, and dbox — trade filesystem simplicity against IMAP performance, backup ergonomics, and operational overhead. Picking wrong shows up later as slow LIST/SEARCH responses, inode exhaustion, or a migration project you did not budget for.

This guide assumes a common production profile: a Linux server on a POSIX filesystem (ext4 or XFS), concurrent appends from an MTA or submission service, IMAP clients that expect responsive folder listing and search, backups done with file-level tools like rsync, and a small operations team that wants minimal moving parts. If your constraints differ — object storage backends, NFS, or a Dovecot director cluster — the trade-offs shift and you should re-evaluate.

Behavior described here reflects Dovecot 2.3.x. Format internals and defaults changed across 2.3 releases, so verify against your installed version with doveconf -n before committing.

Comparing the three formats

What the trade-offs mean in practice

maildir maximizes portability. Every message is a standalone RFC 822 file, so you can inspect, restore, or move mail with plain Unix tools, and a corrupt index never costs you data — indexes are pure cache. The cost is metadata pressure: a folder with 100,000 messages means 100,000 inodes and directory scans that make LIST and STATUS expensive on cold caches. On ext4 with millions of users' worth of messages, inode exhaustion is a real failure mode.

mdbox stores many messages per file (default rotation around 10 MB per m.* file) and relies on Dovecot's index files to locate them. You keep per-mailbox granularity — useful for per-folder restores — while cutting file count by orders of magnitude. Expunged messages leave dead space until you run doveadm purge, so add that to routine maintenance. This is the most common production choice for the constraint set above: near-maildir operability with much better IMAP responsiveness.

dbox (specifically multi-dbox, mdbox's append-oriented sibling in the sdbox/mdbox family) optimizes write-heavy ingestion and storage density. The price is operational: you must watch log growth, tune compaction, and accept that recovery leans harder on index integrity. Choose it when append throughput is the measured bottleneck, not by default.

One cross-cutting caution: durability guarantees depend on the filesystem honoring fsync. Use ext4 or XFS with standard journaling mount options; if you ever see fsync warnings in the Dovecot log, treat them as data-safety signals, not noise.

Concrete implementation: mdbox

Set the location in /etc/dovecot/conf.d/10-mail.conf (as root, then reload Dovecot):

mail_location = mdbox:~/mdbox
maildir_copy_with_hardlinks = no

The second setting is defensive: hardlink copying is fast but couples message files in ways that complicate restores; disabling it costs some copy performance for operational safety.

Validate the configuration before touching users:

# Run as root on the Dovecot host
doveconf -n | grep mail_location

Expected: the mdbox path you set, with no syntax errors from doveconf -n itself. Then create a test user, append a few messages over IMAP, and check integrity:

doveadm mailbox list -u testuser
doveadm mailbox status -u testuser messages INBOX
doveadm force-resync -u testuser INBOX
doveadm index -u testuser INBOX

You should see the appended message count in the status output and no errors from the resync. Do not invent success — if counts mismatch, check /var/log/mail.log (or your configured log path) for fsync or index warnings before proceeding.

Migrating an existing user base

Format changes are not in-place edits. The supported path is doveadm sync (the same engine as dsync), which copies mail between locations and can run incrementally: sync once while live, take the user offline or block delivery briefly, run a final sync, then switch mail_location. Example for one user:

doveadm sync -u alice maildir:~/Maildir

Run this as root or via doveadm's userdb lookup. Risks: a final sync window where new mail must not arrive at the old location, and the need to verify message counts per mailbox before cutting over. Test the full cycle on a staging account first.

Limitations and how to check your choice

Index behavior, purge semantics, and defaults vary across 2.3 point releases — confirm with doveconf -n and your version's documentation rather than assuming. File-level backup of mdbox/dbox captures large files that change between runs, so rsync deltas are bigger than maildir's; if backup bandwidth is the binding constraint, that cuts against mdbox. Finally, monitor after rollout: doveadm stats and log review for fsync warnings and purge/compaction activity will tell you within weeks whether the format matches your actual workload.