Supabase backup tools compared
Six ways to back up a Supabase project, compared on what they actually capture. Every claim links to the vendor's own documentation.
- Every row sourced
- Our own limits listed
- Checked 9 September 2026
The short version
Supabase native backups and PITR protect the database inside your project, but exclude Storage objects and cannot be restored elsewhere if the project itself is gone. pg_dump, pgBackWeb and SnapShooter give you a portable database dump but leave Storage, Edge Functions and configuration to you. SimpleBackups and ReviveDB both cover the wider project. The difference between those two is that SimpleBackups writes to a bucket you own, while ReviveDB stores the copy itself and restore-tests every database backup automatically.
Coverage by option
What each option captures. Follow the source links under the table to verify any row.
| Component | Supabase built-in | SimpleBackups | Ottomatik | Generic Postgres tools | ReviveDB |
|---|---|---|---|---|---|
| PostgreSQL database | Yes | Yes | Yes | Yes | Yes |
| Auth users and identities | Yes | Yes | Partial | Partial | Yes |
| Storage object bytes | No | Yes | No | No | Yes |
| Edge Function bundles | No | Yes | No | No | Yes |
| Project configuration1 | No | Yes | No | No | No |
| Restore-tested automatically2 | No | Unclear | Unclear | No | Yes |
| Restore test compares more than row counts3 | No | Unclear | Unclear | No | Yes |
| Copy survives project deletion | No | Yes | Yes | Yes | Yes |
| Backup can be downloaded | Partial | Yes | Yes | Yes | Yes |
| Self-hostable | No | No | No | Partial | No |
| Bring your own bucket | No | Yes | Yes | Yes | No |
| Price4 | $25/mo | $49/mo | $14/mo | Free–$14/mo | Free / €9/mo |
- Supabase built-in covers both daily backups and PITR. A daily backup can be restored from the dashboard; a PITR snapshot is not directly downloadable. Both stay with the project and are removed when the project is deleted.
- SnapShooter, Supabackup, pgBackWeb and pg_dump are listed together because they cover exactly the same components: the database and nothing else. They differ in who runs them, from fully managed to your own cron job.
- 1ReviveDB restores bucket settings and Function deploy metadata. General project settings, Auth providers and external service connections stay with the destination project.
- 2Restore-tested means the database dump is restored into an isolated PostgreSQL instance and compared against a capture-time inventory, on every backup. For ReviveDB this covers the database. Storage object bytes and Edge Function bundles are verified by SHA-256 hash instead. Where a vendor does not document a restore test, this is recorded as not documented rather than as an absence.
- 3A restore can return every row and still be wrong: permissions you revoked, policies on Storage tables, a scheduled job that came back switched on. ReviveDB compares schema and structure, grants on tables, sequences, functions and schemas, RLS policies and forced RLS, sequence values, extensions and their schema, publication membership and scheduled jobs, alongside row counts. Where a vendor documents a restore test without saying what it compares, this is recorded as not documented.
- 4Lowest paid tier, as published by each vendor on the date below. Supabase, SimpleBackups, SnapShooter and Ottomatik quote in dollars excluding VAT; ReviveDB quotes in euro including VAT. Supabase PITR adds $100 per month per 7 days of retention on top of the plan. pgBackWeb and pg_dump have no licence cost but you pay for the server, the storage and your own time.
Which one fits
SimpleBackups
- Choose SimpleBackups when
- Backups must land in infrastructure you control.
- Choose ReviveDB when
- Supabase is what you need protected, and you want the backup verified.
Ottomatik
- Choose Ottomatik when
- Losing an hour of database writes would hurt.
- Choose ReviveDB when
- Your project is more than its database.
Supabase PITR
- Keep PITR when
- Your main risk is a bad write, not losing the project.
- Add ReviveDB when
- You could lose access to the project itself.
pg_dump on a schedule
- Keep your own pg_dump when
- You already run reliable scheduled jobs, and someone owns that pipeline.
- Choose ReviveDB when
- You would rather not own that pipeline.
You take on the monitoring, the alerting, the credential rotation and the restore drills.
What ReviveDB deliberately does not do
Ruling us out quickly is more useful to you than a longer pitch. These are deliberate, and none of them are on the roadmap.
- Supabase only. No Neon, RDS or self-managed PostgreSQL.
- No bring-your-own bucket and no self-hosting.
- European storage only. No US or APAC region.
- Daily is the shortest schedule. PITR is the tool for second-level recovery.
- Secret values are never copied. Edge Function secrets and Vault contents stay with you.
Common questions
Sources
- Supabase built-in: Supabase docs, Backups, Supabase pricing
- SimpleBackups: SimpleBackups for Supabase, SimpleBackups pricing
- Ottomatik: Ottomatik for Supabase, Ottomatik pricing
- Generic Postgres tools: SnapShooter PostgreSQL backups, Supabackup, pgBackWeb on GitHub, Supabase CLI, db dump
Create your first recovery point free.
Connect one Supabase project. The first backup starts right away and shows what can be recovered. No card required.