Supabase backups that are tested before you need them
ReviveDB restores every database dump into a clean PostgreSQL database and compares the result 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. ReviveDB downloads the stored dump, restores it into a new PostgreSQL database and compares the result with an inventory from the same repeatable-read snapshot. The recovery point is verified only when the restore and comparison pass.
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 into isolated PostgreSQL
Download the stored dump and run pg_restore with --exit-on-error against a database created from template0. Existing objects cannot hide something missing from the dump.
- 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
ReviveDB uses the strongest check that fits each component and names the boundary 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 |
| Supported project configuration | Captured in the recovery manifest | Available and unavailable settings listed |
| Secret values | Never copied | Secret names become manual recovery actions |
What a green backup job can miss
Creating and uploading a file proves less than completing a restore. Automated verification exposes problems while the source project is still available.
- 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.
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.