Platform
Postgres versions & upgrades
Patch upgrades, 15 → 17, hb1, maintenance windows, compatibility report, dry-run and rollback.
Every project runs one Postgres image (Supabase). In Settings → Infrastructure → Postgres version you see the current version and the available targets (with a changelog link), run a compatibility check, schedule an upgrade and follow its progress.
Upgrade types
| Type | Example | Downtime | How |
|---|---|---|---|
| Patch | 17.6.1.136 → 17.6.1.178 | tens of seconds | database container image swap; data stays in place |
| Variant | standard → hb1 (pg_ivm, pg_search) | same | same; hb1 → standard is blocked while pg_ivm/pg_search are in use |
| Major | 15 → 17 | usually 1–5 min | pg_upgrade in copy mode; the old data directory is kept until you confirm |
You can create a new project on PostgreSQL 15 (postgres_version: "15" in the API/MCP) and upgrade to 17 later.
Safety
- Compatibility check: extension availability,
reg*columns, UNLOGGED tables, read replicas, disk space and estimated downtime. Changes nothing. - An automatic backup right before the change, plus a data fingerprint (row counts, roles, extensions, schema grants) compared afterwards.
- Automatic rollback: if start or verification fails we return to the previous image (and data directory for major upgrades) and notify the owners.
- Dry-run (major upgrades): a full rehearsal on a copy of the database that measures real downtime without touching the running project.
- Rollback after a major upgrade until you confirm (14 days by default); writes made after the upgrade are lost. Confirming deletes the old data directory.
- After a major upgrade earlier PITR restore points are unavailable (a new base backup is taken automatically); read replicas must be removed before and re-created after.
Maintenance window and notifications
Start immediately or schedule (Warsaw time, 10 minutes to 30 days ahead). Owners and admins get an in-app notification and e-mail when it is scheduled, reminders 24 h and 1 h before, and a message on start, success or failure (also on your Slack, Discord and webhook channels).
API, MCP and CLI
GET /api/v1/projects/{ref}/postgres-version
POST /api/v1/projects/{ref}/postgres-version/check {"to": "17.6.1.178"}
POST /api/v1/projects/{ref}/postgres-version/upgrade {"to": "17.6.1.178", "scheduled_for": "2026-10-20T00:00:00Z", "dry_run": false}
GET /api/v1/projects/{ref}/postgres-version/upgrades/{id}
DELETE /api/v1/projects/{ref}/postgres-version/upgrades/{id}
POST /api/v1/projects/{ref}/postgres-version/confirm
POST /api/v1/projects/{ref}/postgres-version/rollback {"acknowledge_data_loss": true}hostbase db upgrade
hostbase db upgrade --check --to 17.6.1.178
hostbase db upgrade --to 17.6.1.178 --at 2026-10-20T02:00:00+02:00
hostbase db upgrade --to 17.6.1.178 --dry-run
hostbase db upgrade confirm | rollback | cancel <id> | log <id>MCP: get_postgres_version, check_postgres_upgrade, upgrade_postgres, cancel_postgres_upgrade, confirm_postgres_upgrade, rollback_postgres_upgrade.