Stalwart v1.0 Release Guide: Speed Gains, Document Search and a Safe Upgrade Path for Mail Admins

The first commit behind today's Stalwart landed on 3 October 2021, in a small repository then named mail-parser - a Rust library for reading e-mail headers and nothing more. Five years on, that same code base is a complete mail and collaboration server carrying its first stable tag, v1.0. If you install, tune or migrate mail software, the parts worth your attention are concrete rather than glamorous: requests spend fewer database round trips; the search index records word positions, so phrase queries stop guessing and a mailbox scan reads only the blocks that mailbox touches; text hidden inside attachments becomes searchable; and the schema has been declared final, which is the release team's way of saying future upgrades should be install steps, not migration weekends.

Audit the scope before you judge the version: JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV, a built-in spam filter, clustering, and half a dozen storage backends. The project framed 1.0 around two goals - demonstrable speed and long-term data stability - and folded in features such as full-text search inside PDF and office documents.

Quick take: six things that change in daily operation

• Parsing is vectorised. SIMD and SWAR kernels replace per-byte loops in header, MIME and quoted-printable handling, so a 10 MB message no longer generates an enormous number of iterations.
• Delivery writes are cheaper. Identifiers are assigned inside the same write transaction, and read-modify-write updates such as adding a keyword or appending to a search index run as merge operations inside the backend.
• Mailbox views are cached. Each account's message index is held in memory in a compact packed form, so IMAP sorting, threading, flag fetches, property searches and resynchronisation are answered with few or no database reads.
• Search was rebuilt. Postings live in blocks of 65,536 documents with word positions kept per message; on a mailbox of 250,000 messages a full-text body search returns in under 4 milliseconds.
• Upgrades stop being disruptive. The database layout is finalised, and this release is described as the last migration of its kind.
• Two prerequisites need attention. Clustering now requires a Redis-based in-memory store, and OAuth behaviour follows the open public client profile.

Where the CPU was going: the parser layer

Five years ago this work was all that existed; today byte searching - header-line endings, MIME boundaries, equals signs inside quoted-printable bodies, the spaces that terminate IMAP tags - still occupies a surprising share of a mail server's time. Two techniques let the processor handle many bytes at once:

• SIMD (Single Instruction Multiple Data) uses wide vector registers - SSE2, SSSE3 and AVX2 on x86-64, NEON on ARM - to compare or transform 16 or 32 bytes with a single instruction.
• SWAR (SIMD Within A Register) does the same with ordinary 64-bit integers, testing all eight bytes of a word through a few arithmetic and bitwise operations, so it runs on every CPU.

Two libraries reach 1.0 together with the server, and their reported margins are unusually blunt:

• mail-parser 1.0, the very crate where this project began, was rewritten from scratch. SIMD kernels locate MIME boundaries and header fields, SWAR handles header names, the parsed message lives in a handful of flat vectors, and bodies are decoded only when someone reads them. The CPU-specific kernel is picked at runtime, and each one is fuzzed against a plain scalar reference. It is reported as 3 times faster than the Rust mailparse crate, 9 times faster than Dovecot's own parser, and 15 to 31 times faster than libEtPan!, VMime and GMime on a full parse.
• encodify is a new encoding library with SIMD kernels for Base64, Base32 and quoted-printable - the encodings that carry almost every attachment and non-ASCII header. Decoding a MIME-wrapped Base64 attachment is reported as 22 times faster than the standard Rust base64 crate on an AMD EPYC server, and quoted-printable decoding as 9 times faster than the quoted_printable crate. It now performs every Base64, quoted-printable and IMAP UTF-7 conversion in the server.

Above them the protocol layer got identical treatment. The IMAP command parser is table-driven and scans whole runs of bytes instead of stepping a state machine per character. The SMTP command parser, the JSON parser behind JMAP, the spam filter tokenizers, the HTML-to-text converter, the variable-length integer codec and the log serializers all use SWAR scanning. Even the expression language administrators use for routing and filtering now compiles to compact bytecode with specialised instructions, evaluated in a recycled memory arena. The change set contains close to 200 commits touching more than 1,300 files, and the vast majority exist to make something faster or lighter.

Storage and cache: fewer, faster trips

Fast parsing is wasted if every request waits on storage, so each backend was tuned individually:

• RocksDB: every kind of data lives in a column family configured for how it is accessed - bloom filters for point lookups, large blocks for scans, compaction tuned for churning data - and hot counters such as queue quotas are spread across up to 256 slots to avoid write conflicts.
• PostgreSQL and MySQL: pre-generated, cached prepared statements, chunked iteration with automatic retry, fewer round trips per write; the search backends were reworked as well.
• FoundationDB: reads a transaction will need are prefetched in parallel windows, and large values are assembled in chunks.
• SQLite: page size, cache, memory mapping and WAL settings tuned for a mail workload.

Stored objects are compressed with zstd using dictionaries trained specifically on e-mail, calendar and contact data. Very large accounts get their own cache tier with a memory budget, and cache snapshots can be swapped out to local disk, Redis or the blob store instead of being rebuilt.

Head-to-head: Stalwart v1.0 against Postfix 3.11 and Dovecot 2.4

Internal improvements only tell you whether the software got faster than it was, so the project also measured it against the most widely deployed open-source mail stack: Postfix 3.11 for SMTP and Dovecot 2.4 for IMAP. Both ran on identical Azure servers - 8 AMD EPYC Zen 5 vCPUs, 32 GiB of RAM, local NVMe storage - loaded with the same 1,000 mailboxes plus three very large ones of up to 250,000 messages, and given exactly the same work: receiving mail, delivering it, serving it to IMAP clients. Encryption, password hashing and full-text search were configured the same way on both, and the two systems were measured alternately on the same hardware. Stalwart finished ahead in 35 of the 38 headline comparisons.

Operation	Stalwart v1.0	Baseline (Postfix / Dovecot)	Reported margin
Everyday IMAP client operations	faster in 14 of 15 everyday client operations	Dovecot 2.4	1.4 to 19 times
Login with a full TLS handshake	5.1 ms	28 ms	Stalwart faster
Fetching a 1 MB message	-	Dovecot 2.4	6 times faster
Threading the INBOX	-	Dovecot 2.4	5 times faster
Moving or deleting 100 messages	-	Dovecot 2.4	18 to 19 times faster
Accepting an SMTP message	-	Postfix 3.11	3.6 to 12 times faster
Sustained inbound throughput	5,445 incoming messages per second	723	Stalwart higher
Message visible to an IMAP client after delivery	-	Dovecot 2.4	16 times sooner
Notifying a client waiting in IDLE	3.3 ms	half a second	Stalwart faster
Concurrent IMAP sessions served per second	-	Dovecot 2.4	5.4 times more
Mail relayed before slowdown starts	-	Postfix 3.11	3.8 times more
Full-text body search on a 250,000-message mailbox	3.75 ms	136 ms	Stalwart faster
Moving or deleting 25,000 messages	about a tenth of a second	24 to 34 seconds	more than 200 times faster
Marking every message in a mailbox as read at once	-	Dovecot 2.4 wins all three tests	the only losses

Scale matters here: the gap widens as mailboxes grow. The three tests Dovecot won are all the same operation. Note also that Postfix and Dovecot are not an arbitrary pair - they are the engine under nearly every popular self-hosted mail server, including every open-source dockerized mail server with more than 10,000 stars on GitHub, such as docker-mailserver and mailcow, as well as Mail-in-a-Box. On the strength of these runs the project describes Stalwart as the fastest mail server on the planet; that wording is theirs, not ours.

Data citation: every script, configuration, test scenario and raw result is published in the project's benchmark repository, together with a methodology and an explicit list of caveats such as the differences in disk-sync behaviour between the two systems, so anyone with an Azure account can provision the same servers and re-run the suite. Storage-backend and clustered results are in preparation for the same repository. Feature details come from the changelog.

How the lab produced the numbers

Optimising without measurement is guesswork, so a dedicated benchmarking and stress-testing lab was built for this cycle: Microsoft Azure across more than 30 regions, up to 18 complete test labs running in parallel, several hundred vCPUs busy at once, 35 kinds of test spread over more than 550 individual test cells.

• Protocols: IMAP, JMAP including push over EventSource and WebSocket, SMTP inbound, submission and relay, CalDAV, CardDAV and WebDAV.
• Stores: PostgreSQL, FoundationDB and RocksDB as data stores, Redis as the in-memory store, S3 and the filesystem as blob stores, plus a three-node cluster under mixed load.
• Datasets: 1.6 million messages and 750,000 calendar and contact items across 500 accounts, single mailboxes of 1, 2 and 5 million messages, 100,000 accounts on one server, mail queues of 10 million messages, and DMARC and TLS report floods of a million reports.
• Abuse and storms: 20,000 new connections per second, mass logins, thousands of IDLE and push subscribers per account, hostile and malformed messages, slow-loris clients, oversized literals.
• Soak: Six-hour runs hunting memory growth, cache drift and slow leaks, including one that pushed over 10 million messages through the MTA.

CPU time was sampled with perf and turned into flame graphs; off-CPU analysis showed where threads waited on locks and I/O; the heap was profiled with jemalloc and heaptrack; an instrumented build counted every storage round trip per command. Each fix was measured against the previous build on matched machines before acceptance. The first full round turned up 64 problems, fixed and retested; the second round re-ran everything and fixed 33 more. What that caught, in round numbers: reopening a mailbox with 5 million messages went from 61 ms to 0.21 ms; a JMAP query on an account with 5 million messages went from 3.3 seconds to 12 ms; peak inbound mail throughput on RocksDB nearly doubled, from 9,690 to 18,394 messages per second; and a memory issue where the process held up to 9.6 GB while the actual heap was under 0.4 GB was closed, leaving memory flat through Six-hour soak tests. The lab is now part of internal release routine, not a one-off.

New capabilities you will notice in daily use

• Search inside documents. The text of PDF, Microsoft Office docx, xlsx and pptx, OpenDocument odt, ods and odp, EPUB and RTF files is extracted and indexed, in e-mail attachments and in file storage - so a phrase query finds the contract attached to last year's message, not only the message that mentions it.
• Full-text search of file storage, plus an index queue with per-partition status, retries and rebuilds.
• Metadata: JMAP Object Metadata for e-mails, mailboxes, calendars, contacts and files, and IMAP METADATA (RFC 5464).
• Post-quantum DKIM2: composite ML-DSA-44 and Ed25519 signatures.
• OAuth and OpenID Connect: OAuth Client ID Metadata Documents, per-client scopes for mail, contacts, calendars and files, a revocable list of connected applications, audience matching, opaque token validation and unscoped token policies for external identity providers.
• Storage and operations: a built-in in-memory store for single-node deployments, more authentication methods for Azure Blob Storage, secondary LDAP servers for failover, a memory budget for buffered data, SSRF protection for every outbound HTTP request, and configurable client IP sources and trusted proxy hops.
• AI: AI models and an AI spam classifier in the Enterprise edition, supporting OpenAI-compatible, Anthropic, Gemini and Ollama models.

Permissions, privacy and security settings worth a review

• Least privilege per client. Because scopes are now issued per client for mail, contacts, calendars and files, walk the connected-application list and revoke anything stale.
• Token-policy relaxations are security decisions. The compatibility settings on the OIDC directory weaken checks one by one; treat them as temporary.
• Header trust. Configurable client IP sources and trusted proxy hops decide what the server believes about the connecting client - set them deliberately, not by default.
• Outbound requests are covered by SSRF protection; document extraction runs under strict size and complexity limits so a malformed or hostile file cannot exhaust the server.

Migrating to v1.0: a step-by-step path

Finalising the schema is paid for once: v1.0 uses a new database layout, and a v1.0 server will not open a store created by an earlier version. Two routes exist.

1. Identify your starting version. Deployments on v0.16 can use stalwart-migrate; the tool requires v0.16.27, so earlier 0.16 releases should be updated to it first. Running v0.15 or earlier, or moving users one at a time, points you to the migration guide's second route.
2. Keep the old deployment authoritative. stalwart-migrate only reads from the old store, so the original server stays intact and can be restarted at any point before the switch.
3. Run the initial copy while the old server serves users. Duration does not matter: each later run copies only what changed since the previous pass.
4. Schedule the only downtime. Stop the old version and perform the short final incremental run.
5. Verify client state carries over. Account and message identifiers, IMAP UIDs and change history are preserved, so IMAP and JMAP clients do not re-download anything.
6. Expect re-authentication and a rebuild. Users who sign in with OAuth need to sign in again, and the full-text index is rebuilt in the background after the switch.
7. Alternative: per-account cut-over. The migration proxy sits in front of both servers and routes each user to whichever holds their account, while Vandelay copies accounts across one by one, incrementally. Each account flips one entry in a mapping table, with no downtime for that user, and the old server keeps a full copy until you retire it. The same procedure moves accounts from Dovecot and Postfix. The migration overview compares the two approaches.

Configuration deltas to plan for

Settings structure is largely the same: roughly a hundred keys were renamed for consistent naming, a few objects (OIDC directories, AI models, Azure storage, forwarded headers) were restructured, and stalwart-migrate converts all of it automatically. Two changes need attention before you upgrade:

• Clusters need Redis. A cluster coordinator now requires a Redis-based in-memory store - Redis, Redis Cluster or Redis Sentinel. The old fallback to the data store was slow under load and has been removed; single-node deployments get a built-in local in-memory store instead.
• OAuth follows the open public client profile. The server now fully enforces the OAuth Profile for Open Public Clients, the emerging standard that lets any mail client sign in to any mail server without prior registration; Stalwart's own authorization server supports it out of the box. Many external identity providers do not yet support everything the profile requires, such as Dynamic Client Registration, and some clients do not request the required scopes. Non-conformant providers can be worked around through OIDC directory compatibility settings, at your own risk - and this will bite soon, since popular clients including Apple Mail are adopting the profile, after which their users cannot authenticate against a provider that lacks it. If you depend on an external identity provider, now is the time to ask them to support it.

The WebUI changed shape too: instead of a fixed client id it identifies itself with a Client ID Metadata Document, a URL describing the client. Providers that do not support this can still work - register a client with the provider and set its id in oauthClientId, and the WebUI signs in as before. Administrators stuck mid-migration can post their question to the project's support channel; answers are provided daily throughout the migration period.

Who should move now, and who should wait

• Move now: single-node self-hosters on the 0.16 line, teams drowning in large mailboxes where threading, search and bulk moves dominate the day, and anyone evaluating CalDAV, CardDAV and WebDAV in one binary rather than stitching components together.
• Move with a plan: clustered production environments, because of the Redis requirement; organisations behind external identity providers, because of the OAuth profile enforcement.
• Wait and watch: shops whose clients depend on registered OAuth ids and unsupported metadata documents, and anyone needing the Enterprise-only AI spam classifier.

Common misconceptions

• Migration is a destructive copy. The tool reads only from the old store and writes into a new, empty v1.0 store; the original stays restartable until you cut over.
• Clients will re-download everything. Identifiers, IMAP UIDs and change history carry over; only OAuth sessions restart.
• The numbers are unpublished vendor slides. Scripts, configs, scenarios, raw results, methodology and caveats are in the benchmark repository and re-runnable in the cloud of your choice.
• Everything got faster, including bulk flag updates. Marking every message in a mailbox as read at once is the operation Dovecot still wins.
• Compatibility settings are harmless. Each relaxed token check is a weakened security check.
• Schema stability is cosmetic. It is the whole point of 1.0: future releases are meant to upgrade in place.

FAQ

• Can v1.0 read my existing database? No. Data has to be migrated to the new layout first.
• Which tool for v0.16? stalwart-migrate, and it requires v0.16.27.
• Is downtime mandatory? Only for the final incremental run on the direct route; per-account cut-over with the migration proxy and Vandelay avoids downtime for each user.
• Do I need Redis? Only for clustering; single-node installs get a local in-memory store.
• How fast is search at scale? Under 4 milliseconds for a full-text body search on 250,000 messages in one mailbox, and 3.75 ms versus 136 ms for the same workload in the head-to-head run.
• What file types are indexed? PDF, Microsoft Office docx, xlsx and pptx, OpenDocument odt, ods and odp, EPUB and RTF - in attachments and in file storage.
• Was anything else tested? The comparison named in these headline results is Postfix 3.11 and Dovecot 2.4; storage-backend and clustered comparisons are being prepared.

Action advice

• Pin your current version and confirm whether you land on the stalwart-migrate route or the per-account route before touching anything.
• Provision Redis if you run a cluster; budget it as a hard dependency, not an optimisation.
• Audit your identity provider against the open public client profile now - Dynamic Client Registration support is the usual gap.
• Rehearse the incremental copy on a snapshot so you know how long the final short run actually takes.
• Re-run the published benchmark scripts on your own hardware before committing; the caveat list, including disk-sync behaviour, applies to your workload too.

Our read at MyTechDailyNews: judge this release on the boring parts. Vectorised parsing and fewer storage round trips are what make a big mailbox pleasant; a finalised schema is what makes the next twelve months predictable; and a public benchmark repository is what lets you disagree with the vendor in your own data centre rather than in a forum thread. Stalwart v1.0 is available for download, and feedback is open. For migration notes or corrections from your own deployment, write to Tech Daily at hello@techdaily.com.

Reviewed for the Software desk by Sarah Chen, Tech Daily.