Supabase backup
Back up the whole Supabase project. Recover it as one.
ReviveDB protects your database, Auth, Storage files, Edge Functions and recoverable project configuration in one off-platform recovery point—then checks the pieces that can be verified automatically.
The recovery boundary
PostgreSQL is the core, not the whole project
Supabase spreads application state across PostgreSQL and several platform APIs. A useful backup has to preserve those boundaries without pretending everything belongs in one database restore.
Database and Auth data
Schemas, rows, identities, RLS policies, functions, triggers, grants, sequences, publications and supported extensions.
Storage buckets and files
Bucket settings, object metadata and the actual bytes, read back and verified with SHA-256.
Edge Functions
Function bundles and deployment metadata, stored off-platform and verified by hash before recovery is accepted.
Project configuration
Recoverable Auth, Data API, Realtime and Storage settings captured in a versioned recovery manifest.
Secrets and new keys
Secret names are inventoried without copying their values. Manual key and secret work becomes an explicit checklist.
Three different kinds of protection
These approaches complement each other. Native backups are strong for database rollback. General tools are flexible. ReviveDB focuses on reconstructing a Supabase application across component boundaries.
| Component | Supabase database backup | General backup platform | ReviveDB |
|---|---|---|---|
| PostgreSQL database | Included | Usually included | Restored and compared |
| Auth users and identities | Database state | Depends on dump scope | Platform-aware migration |
| Storage object bytes | Not in database backups | Separate job or add-on | Included and hash-verified |
| Edge Functions | Separate from database backup | Separate job or add-on | Bundles captured and verified |
| Project configuration | Separate recovery work | Usually exported separately | Supported settings in one manifest |
| Secret values | Manual | Depends on setup | Checklist generated; values never copied |
| Recovery result | Database restore | Artifacts or separate jobs | One component-aware report |
Supabase documents that its database backups exclude Storage object bytes and that restoring to a new project requires separate work for several platform components. See the official database backup documentation and new-project restore documentation.
Provider-aware recovery
The moat is in the restore
Copying files is necessary. Knowing how Supabase-owned state can be restored safely—and proving the result—is the harder part.
- 1
Connect with Supabase OAuth
Choose a project without pasting API keys. Recent projects can use temporary database access; older projects may need a database-password fallback.
- 2
Capture one recovery point
Create the consistent database dump, copy Storage bytes and metadata, store Function bundles, and inventory supported configuration.
- 3
Verify every component
Restore the database into isolated PostgreSQL, compare its inventory, hash-check objects and bundles, and detect project changes during capture.
- 4
Recover in the right order
Preflight compatibility, make a safety backup for rollback, restore database and Auth data, then Storage, Functions and safe configuration.
- 5
Finish with an honest report
Any automatically verifiable mismatch fails the restore. Secret values and non-transferable provider settings remain explicit manual actions.
Complete does not mean pretending secrets are portable
ReviveDB never stores Edge Function or Vault secret values. New project API keys, secret values and provider infrastructure remain controlled manual steps, listed in the recovery report instead of hidden behind a green badge.
- Secret names inventoried
- New API keys reported
- Destructive reconcile requires confirmation
- Automatically detectable mismatches fail
Supabase backup questions
Create your first complete recovery point
One Supabase project, up to 1 GB, no card required.