Backup verification
Every database dump is restored into a clean PostgreSQL database and compared with an inventory from the same snapshot. Storage files and Edge Function bundles are checked separately by byte count and SHA-256 hash.
What is a verified Supabase backup?
A verified Supabase backup is one whose database dump has completed a real restore test, not only an upload. The stored dump is restored in an isolated environment and the result is compared with an inventory captured from the same snapshot.
How every database backup is restore-tested
Verification is part of each backup run. It is not a quarterly drill or a manual check performed after an incident.
- 1
Capture the source inventory
Export one repeatable-read snapshot to pg_dump and the inventory collector. This keeps writes during the backup from creating false differences between the two.
- 2
Restore in a Supabase-aware environment
Restore the stored dump into a clean, isolated database running Supabase's own PostgreSQL build, so the extensions a project uses are available to restore into. A dump that needs something the target cannot provide fails here rather than during recovery.
- 3
Compare source and restore
Compare schemas, tables, columns, constraints, indexes, views, functions, policies, RLS state, grants and other database objects. Exact row counts are also compared when the source was captured in exact mode.
- 4
Keep the result with the recovery point
Record the restore outcome, duration, row-count mode and mismatch counts by category. Customer schema, table and column names stay out of the downloadable report.
Restore-tested and hash-checked are different claims
Each component gets the strongest check that fits it, and the boundary is named plainly. Only the PostgreSQL database is restored during automated verification.
| Component | Verification method | Recorded result |
|---|---|---|
| PostgreSQL database and Auth data | Restored into isolated PostgreSQL and compared | Restore result and inventory comparison |
| Storage object bytes | Byte count and SHA-256 hash checks | Object manifest and verification state |
| Edge Function bundles | Bundle capture and SHA-256 hash checks | Function manifest and verification state |
| Secret values | Never copied | Secret names become manual recovery actions |
What a restore puts back
Recovery includes more than rows. The supported restore path reapplies the captured objects below; the report shows the checks performed. Older recovery points may contain less verification information.
Schema and data
Tables, rows, column types, defaults, constraints, indexes, views and materialized views.
Functions and triggers
Function bodies with the search path they were created with, and the triggers that call them.
Access as you set it
RLS policies and forced RLS, grants on tables, sequences, functions and schemas, and the rights you deliberately revoked.
Objects outside your schemas
Policies on Storage and Realtime tables, event triggers and Realtime publication membership. A schema-scoped restore skips these, so they are replayed separately.
Extensions and scheduled jobs
Extensions in the schema they were installed in, pg_cron jobs with their schedule and whether they were on or off, and queues.
Beyond the database
Auth users, Storage files checked by SHA-256 hash, and Edge Function bundles.
Secret values are not copied. Unsupported extensions or dependencies can prevent recovery; compatibility checks run before destructive work where the limitation can be detected. These checks do not execute your application or prove every possible Supabase configuration. For second-level recovery, use Supabase point-in-time recovery.
Backup checks and our own recovery tests
Each completed database backup is restored into isolated PostgreSQL. Files and Function bundles are hash-checked. Separately, our regression fixtures exercise changed records, access restrictions and file recovery. These tests cover our implementation; they do not sign in to, run or simulate every customer application.
What a green backup job can miss
A restore test checks the saved artifact while your project is still available. We do not claim unusable dumps are common: we make the result of the check visible.
- A dump that stopped early or cannot be read back
- Extensions or database objects unavailable on the restore target
- Missing grants, policies or row-level-security state
- Row-count differences when exact row-count mode applies
- Storage files or Function bundles whose copied bytes do not match
Evidence you can inspect
The report lists the compared object categories, row-count mode, restore duration and mismatches by category. It does not include customer schema, table or column names. The implementation is public, so the word verified refers to a specific procedure.
Two questions come up in most security reviews: are the backups held outside the environment they protect, and has anyone restored one. Recovery points are stored with a separate provider in the European Union, and every database recovery point carries a dated restore test you can open and export.
Supabase backup verification questions
Create a checked recovery point
Connect one Supabase project free. The database is restore-tested and the result is kept with the recovery point.