ntfy v2.31.1, published today, is the fix for the database load that arose after v2.31.0 and made the project roll back its own hosted service, ntfy.sh. An index makes the offending reconnect path cheap again, and the release also changes how a newer database schema is handled, so rollbacks need no manual step.
The regression
v2.31.0, from 15 October, fixed messages that could be lost when a client reconnects, like a phone switching networks, right when messages are published. The mechanism: every server reads newly written messages from its message cache once a second and sends them to subscribers who missed them; in load tests with server restarts and crashes, that brought lost messages down from 465 to 2 out of about 615,000. The side effect came from the same feature: reconnecting with since=<message ID> read every message of the topic from the database, and right after the upgrade that overloaded ntfy.sh’s database. The project rolled its hosted service back.
The fix
The fix in v2.31.1 is an index on the message cache: (topic, published, id) on PostgreSQL, (topic, published, time) on SQLite. Reconnects with since=<message ID> become cheap again, “cheaper than in v2.30.0” in the release notes’ words. The same release lets ntfy start “with a warning instead of failing when the database schema is newer than this version of ntfy supports,” so a rollback or a rolling cluster upgrade needs no manual schema change. Web app fixes ride along: the wrong topic opening when the same topic is subscribed on two different servers, notification warnings that can now be dismissed, and a crash when the subscribe dialog opens before the topic list loads.
The upgrade notes
For self-hosters, the details are worth reading before upgrading. The message database schema moves from version 16 to 17, adding the index; that part happens as part of the update. Downgrading to v2.31.0 or earlier afterwards “requires setting the version back by hand first”, and the notes carry the SQL for both databases: UPDATE schema_version SET version = 16 WHERE store = 'message' on PostgreSQL, or UPDATE schemaVersion SET version = 16 WHERE id = 1 in the SQLite cache-file. From this release on, a newer schema only logs a warning. One carryover from v2.31.0 is still in force: a since=<message ID> reconnect can also return messages published in the same second, so none are skipped when several servers write out of order; the ntfy apps and web app drop those by ID, while your own scripts may see a few duplicates.
My read
An upgrade that the project’s own deployment caught, with a fix out in two days, is the useful kind of incident. The shape of the result is honest too: v2.31.0’s reconnect behavior stays, made affordable by an index, and the schema warning turns rollbacks from a procedure into a non-event. For anyone self-hosting a busy ntfy server, v2.31.1 is the version to be on; the downgrade SQL matters only if you go back.
Source: the v2.31.1 release notes and the v2.31.0 notes.