Stalwart's documentation answers two sizing questions well: what a tiny install needs, and how many mailboxes one node can carry in a cluster. The range most organisations actually sit in, a few hundred to a few thousand mailboxes, is left for you to work out. This article fills that gap from the docs themselves, tier by tier, for 200, 2,000 and 10,000 mailboxes.
One thing up front. We run Stalwart in production for a university with 10,000 mailboxes, but we have not load-tested it and we are not publishing benchmark numbers. Every figure below is either quoted from Stalwart's own docs, with a link, or plain arithmetic you can redo with your own quotas.
Stalwart sizing at a glance
| Mailboxes | Nodes | Stores | Disk ceiling at a 5 GB quota |
|---|---|---|---|
| 200 | 1 | RocksDB for all four roles (Docker default) | 1 TB |
| 2,000 | 1 is enough for capacity | PostgreSQL for data, S3-compatible storage for blobs | 10 TB |
| 10,000 | 1 can carry it; 3 or more for high availability | Shared stores: PostgreSQL or FoundationDB, distributed blobs, a search engine, Redis or Valkey | 50 TB |
The node counts come from Stalwart's sizing page, the disk column is plain quota arithmetic, and real usage is usually far below the ceiling (see the 10,000-mailbox section for what one production server actually holds).
What Stalwart's docs actually commit to
- Idle memory: about 100 MB, per the system requirements page.
- Small installs: the same page says 1 GB of RAM is generally enough for roughly 5 to 10 users, and one CPU core for a low-traffic setup of around five users.
- Connections: up to 8,192 concurrent connections by default, shared across IMAP, JMAP, WebDAV, SMTP and POP3. Lowering that limit lowers memory use.
- Per node: the cluster sizing page says one well-configured node can handle 10,000 to 50,000 active mailboxes, and that heavy-use environments should plan for about one node per 5,000 to 10,000 active users.
- High availability: a minimum of three nodes, odd numbers preferred, scale out when a resource sits at 70 to 80 percent, and provision for two to three times the starting load.
Notice what's missing: there is no RAM-per-mailbox figure and no disk figure at all. That's not an oversight you can fix with a forum post. Stalwart's memory use depends mostly on cache settings, and its disk use depends on which storage backends you attach.
Memory is mostly cache, so you choose it
The performance page calls the email metadata cache the most important one, because IMAP clients hit it constantly, and asks for enough memory to cache metadata for every concurrently connected user. The cache reference lists the defaults: 50 MB for message metadata, 20 MB for accounts, 10 MB each for contacts, events, files and access tokens, plus a handful of small DNS caches. Those defaults are deliberately modest.
So the practical rule is: start with the defaults, watch the process's resident memory and the server's cache-hit metrics during a busy morning, and raise the message cache when hit rates drop. A server that "uses more RAM than the docs say" after a big IMAP import is usually just filling its caches up to their limits, which is what they are for.
Storage is four decisions, not one
Stalwart splits storage into four roles, described on its database choice page:
- Data store: metadata such as folders, flags, calendars, contacts and settings.
- Blob store: the message bodies and attachments, which is where nearly all of your disk goes.
- Search store: full-text indexes.
- In-memory store: short-lived data for rate limits, sessions, clustering and spam checks.
On a single node you can put all four in one backend. The Docker install defaults all of them to RocksDB on local disk, which Stalwart recommends for single-node installs. For clusters, the cluster storage page recommends FoundationDB for data, calls PostgreSQL mature and well performing, asks for a dedicated engine such as Elasticsearch or Meilisearch for search (a general-purpose database adds write amplification there), and Redis or Valkey for in-memory data. One warning from the docs is worth taking literally: changing the backend later means migrating your data. Pick with the 10,000-mailbox version of yourself in mind.
Disk: do the arithmetic yourself
Because the docs give no number, size the blob store from your quota policy. As an example, 200 mailboxes with a 5 GB quota is a 1 TB ceiling, and 2,000 at the same quota is 10 TB. Most mailboxes never reach their quota, so real usage will be lower, but the ceiling is what you plan backups and growth around. Add room for the search index, and remember that storage I/O speed, not size, is what the sizing page names as critical for delivery, indexing and search.
200 mailboxes
One node is plenty. RocksDB for all four stores keeps things simple, and Stalwart's built-in spam filter means there is no separate Rspamd to size. The 1 GB floor in the docs is for five to ten users, so give a 200-user server more than that and leave headroom for cache; the docs do not publish a per-user figure, so measure after the first busy week rather than guessing. More than one core helps once a few dozen phones sync at the same time. Back up by snapshotting the whole data volume, and test a restore once before you need it.
2,000 mailboxes
By the docs' own numbers this is still well inside what one node can carry. The reason to change anything here is operations, not capacity. Moving the data store to PostgreSQL and the blobs to S3-compatible object storage means backups, replication and monitoring use tools your team probably already runs, and the mail server stops being a special snowflake. If users search old mail a lot, this is also the point where a dedicated search engine starts to pay off. Make sure submission on port 587 is actually listening before you migrate clients; in our install it was not on by default.
10,000 mailboxes
A single node can, on paper, handle this. The question at this size is what happens when that node goes down on a Monday morning. The docs say high availability starts at three nodes. That is how we planned it: several Stalwart nodes on shared stores, metadata in PostgreSQL with a replica, message blobs in distributed MinIO, a message bus for coordination and HAProxy in front. The production server still runs as one node today, with everything in PostgreSQL, which is exactly the risk that plan is meant to remove. The details, including what we ran into with version 0.16's configuration model, are in our mailcow vs Stalwart vs Mailu comparison at 10,000 mailboxes.
For a sense of real usage rather than quota: on 30 September 2026 our production node (Stalwart 0.16.13, 24 cores, 60 GB of RAM) held about 559 GB in PostgreSQL for roughly 10,000 mailboxes, with all messages and attachments in the database. That works out to about 56 MB per mailbox on average, a small fraction of any normal quota, and its 3 TB disk was 43% full. It is one server at one point in time, not a benchmark, but it shows how far the quota ceiling overstates the disk you need on day one. How we moved those mailboxes across is in our self-hosted migration plan, and the cost side in the case study.
Two caveats. The docs recommend FoundationDB for distributed setups, and the default Docker build does not include it, so plan a custom build if you go that way. We chose PostgreSQL because we already knew how to run it. And read replicas and sharded stores are Enterprise features according to Stalwart's edition comparison; basic clustering is in the Community edition.
Stalwart vs Dovecot: you're sizing different things
Dovecot is an IMAP and POP3 server. A typical Dovecot install sits behind Postfix for SMTP, with Rspamd for spam and often a separate CalDAV server, so you size and patch four or five daemons. Stalwart is one Rust binary that does SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV and WebDAV with spam filtering built in, so you size one process and its stores. Dovecot has decades of production history and a huge body of tuning knowledge. If your Postfix and Dovecot setup works, resource use alone is not a reason to switch. Protocol breadth, JMAP, and running one service instead of five are the better reasons.
If your server has restricted outbound access
The requirements page lists outbound connections the server needs: GitHub releases for the admin web UI bundle on first start (without it, /admin returns 404), your ACME directory for certificates, and DNS on port 53. On a locked-down network, plan for those before installation day, not during it. Deliverability is the next wall; our Outlook 550 5.7.515 guide for self-hosted servers covers the checks.
Where FanMail fits
FanMail is the webmail and admin layer we built on top of Stalwart: a JMAP client for users and an admin panel for the server, deployed on your own infrastructure. The sizing above applies to it unchanged, because the mail server underneath is plain Stalwart. To check whether running your own server pays off at your size at all, try the self-hosted email cost calculator. Why we built the webmail on JMAP rather than IMAP is covered in JMAP vs IMAP for webmail.
If you are comparing this against a hosted plan, our breakdown of Zoho Mail pricing in 2026 lists every plan and what each one leaves out.
Frequently asked questions
What are Stalwart's minimum system requirements?
Stalwart's docs say it idles at about 100 MB of RAM, that 1 GB is generally enough for 5 to 10 users, and that one CPU core covers a low-traffic setup of around five users. There is no official disk minimum because disk use depends on your storage backend and quotas.
How much RAM does Stalwart need for 200 users?
Stalwart does not publish a per-user figure. Most memory goes to caches you configure, so start above the 1 GB small-install floor, keep the default caches, and size up from the resident memory and cache-hit rates you see during peak hours.
How many mailboxes can one Stalwart node handle?
According to Stalwart's cluster sizing page, a single well-configured node can handle 10,000 to 50,000 active mailboxes, depending on usage, concurrency and backend speed. For high availability the docs recommend at least three nodes.
Should I use RocksDB or PostgreSQL with Stalwart?
RocksDB is the recommended choice for a single node and the Docker default. For a cluster, the docs recommend FoundationDB and describe PostgreSQL as a mature option. Switching later requires a data migration, so decide early.
How much disk does Stalwart need per mailbox?
Stalwart publishes no per-mailbox disk figure, because it depends on your storage backend and on how much mail people keep. Plan backups and growth around your quota ceiling (mailboxes times quota). As one real data point, our 10,000-mailbox server held about 559 GB, roughly 56 MB per mailbox on average.
Is Stalwart lighter than Dovecot?
They do different jobs, so a direct comparison misleads. Dovecot is an IMAP and POP3 server that usually runs next to Postfix, Rspamd and a CalDAV server. Stalwart is one process covering SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV and WebDAV with spam filtering built in. Compare the whole Dovecot stack with one Stalwart node, not Dovecot alone.
What outbound access does a Stalwart server need?
According to the requirements page: GitHub releases to download the admin web UI on first start, your ACME directory (such as Let's Encrypt) for certificates, and DNS on port 53 over UDP and TCP, or DNS over HTTPS where configured.
