Supabase already backs up my database. Why ReviveDB?
This is the most common question we get, and it deserves a straight answer instead of a feature grid. Supabase's built-in backups are real, they run without any setup, and if you are on a paid plan you should absolutely leave them on. They are also a database feature with a documented boundary, and everything ReviveDB does lives on the other side of that boundary.
What the built-in backups give you
Per the official backups guide, paid projects get daily automated database backups: 7 days of retention on Pro, 14 on Team, up to 30 on Enterprise. Restores run from the dashboard, and the PITR add-on narrows the recovery point from "last night" to "seconds before the incident". Free projects get no automated backups at all — only manual CLI dumps.
For the incident they are designed for — a bad migration or an accidental delete inside a healthy project, caught within the retention window — they are exactly the right tool, and faster than any external restore.
Where the documented boundary is
Storage files are not in the backup
Supabase is explicit that database backups do not include the objects stored via the Storage API — the database holds only their metadata. Restore the database and every avatar, invoice PDF and upload your users trusted you with is a row pointing at nothing. We wrote up the details in do Supabase backups include Storage?.
The backups live inside the project they protect
Deleting a project permanently removes its backups with it, irreversibly. The same blast radius applies to a compromised account or a lapsed subscription. A copy that shares the fate of its original is a convenience feature; disaster recovery starts with a copy that survives the account itself.
Newer projects cannot download their backups
Projects on recent Postgres versions use physical backups, which are not available for direct download. Your recovery point exists, but it is not portable: you cannot take it to another provider, another region, or a local machine without generating a separate logical dump yourself.
Retention stops at your plan
Seven days on Pro means a corruption or bad write that surfaces after a week and a half is simply outside the window. Data problems are not always loud; the quiet ones are the expensive ones.
No restore is ever tested
A nightly snapshot proves a snapshot ran. It does not prove the restore works, that extensions and sequences survive, or that row counts match — and nobody finds out until the day it matters. This is the industry's oldest backup failure mode, and no scheduled snapshot addresses it.
What an independent layer adds
ReviveDB keeps a complete recovery point outside your Supabase account: the database, Auth state, Storage file bytes verified by hash, Edge Function bundles and a recoverable configuration manifest, in one versioned unit. Every run is then restored into a scratch database and compared against the source inventory — structure, row counts, sequences, extensions — before it is allowed to call itself verified. Retention runs to 30 or 60 days on paid plans, and the free tier keeps one project on weekly, fully verified recovery points.
Keep both — this is 3-2-1, not either/or
Native backups and an independent copy answer different failure questions:
- Keep native backups and PITR for fast, precise rollback inside a healthy project.
- Keep an independent verified copy for everything the platform cannot cover about itself: account-level failure, Storage bytes, portability, longer retention, and proof the restore works.
If you are choosing between the database options themselves, our daily backups vs PITR guide walks through RPO and RTO. Whichever you pick there, the question this post answers stays the same: the built-in backup protects your database inside Supabase. Something still has to protect your project from everything else.