Stalwart announced its first stable release on October 26, but existing installations need a migration before they can use it. The Rust mail and collaboration server's 1.0 announcement says the database schema is now finalised. A 1.0 server cannot open a store created by an earlier version.
For administrators, that makes the immediate decision a storage and maintenance-window question. Stalwart promises future releases will upgrade in place, but getting onto that stable schema requires a separate destination store. This article examines the release announcement, migration documentation and published benchmark materials. We haven't run the server, migration tool or performance tests.
The upgrade needs room for a second store
The migration guide requires the source deployment to run version 0.16.27. The stalwart-migrate tool copies settings and data into a new, empty 1.0 store while opening the old data store read-only. Administrators need space for a second copy of that store. When an external blob store is reused, message bodies and files can stay there.
The bulk copy can run while 0.16 continues serving users. Repeated runs transfer subsequent changes, followed by a final run with every 0.16 node stopped. The tool also provides verification and a report of objects that were changed, dropped or couldn't be copied. A sensible rehearsal includes reading that report before scheduling the switch.
Client effects are uneven. The guide says account identifiers, IMAP UIDs and change histories survive, so IMAP clients don't need to download their mailboxes again. OAuth users must sign in again. Calendar, contact and file clients fetch their content once more because entity tags change. The full-text index is rebuilt after startup, leaving search results incomplete until that finishes.
Older installations need another route: the release announcement directs users of 0.15 and earlier to its migration proxy and Vandelay, which move accounts individually. It also flags a configuration requirement for clusters: their coordinator now needs a Redis-based in-memory store.
The speed claim has conditions
Stalwart reports winning 35 of 38 headline comparisons against Postfix and Dovecot. Its benchmark repository identifies Postfix 3.11.7 and Dovecot 2.4.5, running on matching Azure machines with eight AMD EPYC vCPUs and 32 GiB of RAM. Dovecot wins the bulk mark-as-read comparisons.
The repository discloses a material difference in durability settings. Postfix flushes each incoming message to disk before acknowledging it; Stalwart and Dovecot, as configured for these tests, don't. That favours Stalwart's SMTP results. Stalwart was also compiled for the specific CPU, while its rivals used standard builds. The workload uses synthetic messages, with spam filtering disabled on both systems.
Those conditions make the results useful for choosing what to test locally. They don't establish how a deployment with different persistence requirements or filtering will perform. The published comparison uses one server per system; storage-backend and clustered benchmarks are still listed as in preparation.
For existing users, the next useful evidence is a verified migration rehearsal with their own data and clients. For prospective adopters, watch for the promised backend and cluster results. Those will address deployment choices the current single-server comparison leaves open.