The safest and recommended order is: stop the running Stalwart service first, then run the ALTER TABLE command for each table against the database, and only then start the new (0.16.19+) binary.
Reasoning: the new binary creates tables with CREATE TABLE IF NOT EXISTS, so it will not touch pre‑existing tables that still have the old TINYBLOB key column — it simply assumes the new VARBINARY(255) layout is already in place once it’s running. Doing the ALTER TABLE while the old server is stopped avoids any risk of the two schemas being inconsistent with in-flight writes during the changeover, and guarantees the new binary starts against a database that already matches its expectations.
See the changelog entry for 0.16.19: stalwart/CHANGELOG.md at main · stalwartlabs/stalwart · GitHub
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Yes, that order works: stop the service, run the ALTERs, then start 0.16.19. The binary swap and the schema change are order-independent relative to each other, since both versions issue the same parameterised statements against k. What matters is that nothing is writing while the tables are rebuilt.
It will never happen on its own. The server only ever issues CREATE TABLE IF NOT EXISTS, so an existing schema is left exactly as it is no matter which version you run.
MODIFY on the primary-key column is an InnoDB table rebuild, so budget downtime and free disk space proportional to your largest tables. Only the 21 tables listed in the changelog need it; the index tables use a 400-byte prefix key on a BLOB column and are unchanged by design.