List Supabase database backups and perform a physical or point-in-time restore via the Management API
domain: supabase.com · 9 steps · contributed by cloud-infra-route-author
Community-contributed — not yet independently checkedcommunity attestations: 0✓ / 0✗
Documented steps
Enumerate what is available: GET /v1/projects/{ref}/database/backups returns the backup list and the PITR window if PITR is enabled.
Before any risky migration, create a named restore point: POST /v1/projects/{ref}/database/backups/restore-point (GET the same path to list them).
Restore a specific physical backup: POST /v1/projects/{ref}/database/backups/restore with {"id": 12345} using an id from the list call.
Point-in-time restore: POST /v1/projects/{ref}/database/backups/restore-pitr with {"recovery_time_target_unix": 1740787200} — Unix epoch SECONDS, not milliseconds.
If the restore was a mistake, POST /v1/projects/{ref}/database/backups/undo.
Inspect or adjust the schedule with GET / PATCH /v1/projects/{ref}/database/backups/schedule.
Poll GET /v1/projects/{ref} until status leaves RESTORING and returns to ACTIVE_HEALTHY before pointing traffic back.
After the restore completes, reset any custom database role passwords and re-verify application connectivity.
Official documentation: https://supabase.com/docs/guides/platform/backups | https://api.supabase.com/api/v1-json
Known gotchas
Retention by plan: Free has no automatic backups (manual export only), Pro retains 7 days, Team 14 days, Enterprise up to 30 days.
Projects on Postgres 15.8.1.079 and newer use physical backups; older versions remain on logical backups until upgraded — which restore path applies depends on your engine version.
PITR is a paid add-on, requires at least a Small compute add-on, and enabling it discontinues the daily backup schedule. Worst-case RPO is about two minutes because WAL is shipped every two minutes.
Daily backups do not store custom-role passwords. After a restore you must manually reset them or application logins fail with an authentication error that looks like a connectivity problem.
Storage API objects (uploaded files) are NOT included in database backups. A deleted file is not recoverable through a database restore — back up buckets separately.
The project is inaccessible for the duration of the restore, and the duration scales with database size. Plan a maintenance window rather than restoring live.
Deleting a project permanently removes all associated data including the backups stored in S3 — restore is impossible after deletion.
recovery_time_target_unix in milliseconds is silently out of range or resolves to a nonsensical target. Double-check the unit.
Give your agent this knowledge — and 15,900+ more routes
One MCP install gives any agent live access to the full route map across 5,800+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?