v3.6.0 — it upgrades itself, and it holds

A database from an older version upgrades itself

• CREATE TABLE IF NOT EXISTS can never add a column, so no column nabiz has ever added reached a self-hosted deployment — the upgrade notes said otherwise.
• From a real v1.0.0 database: the process starts, prints success, /health answers 204 forever, every page returns 500 with no such column: last_status, each round writes checks then throws before the state — alerts stop, pruning never runs.
• The server adds what schema.sql cannot reach and says which:

  [nabiz] added monitors.expect_body, monitors.fail_threshold, state.fails, state.last_status
  

• Verified from v1.0.0, v1.1.0, v2.0.0, v3.0.0 and v3.4.0 schemas: each starts, keeps its history, serves the page.
• Cloudflare has no start to do this at; re-running --file schema.sql there is not an upgrade, and the notes say what skipping the ALTERs looks like.

The page holds for the same 15 seconds the edge holds it

• Measured on 40 monitors with 90 days of history: /health served 10,850 req/s, everything reading the database served 49 — forPage alone 21 of 25 ms.
• / at 50 concurrent: 51 req/s, p50 1222 ms → 321 req/s, p50 158 ms.
• /api/status.json at 50 concurrent: 49 req/s, p50 211 ms → 3,477 req/s, p50 14 ms.
• The window is less than the time between two probes, and every write drops it: a notice is on the page the moment it reloads.
• Probe cadence held to within 200 ms under load; memory oscillated 115–200 MB rather than climbing. The Kubernetes limit is 384Mi, with the measurement beside it.

Upgrading

• A pull. The container adds anything your database is missing and says so.