A Supabase backup on any paid plan runs exactly as its docs describe; whether it has ever produced a working restore is a separate fact, and the settings page never actually asks it, only whether a backup exists. In the audits I’ve run, almost no one has that second fact in hand, because the restore has never been tried.
Founders ask a version of the same thing on r/Supabase: has anyone actually restored one of these backups, or only turned one on. The audit data backs their doubt: measured across 20 of the 21 third-party apps I’ve audited, the Data Integrity & Safety pillar came out at an average of 51.6 out of 100, and the restore nobody has run is a large share of the reason.
None of what follows is a criticism of Supabase’s backup system. It works as documented, the same way the platform half of whether Supabase is safe holds up under its own audits. The gap sits between what the settings page shows and what a founder assumes it means about backing up a Supabase database with real users on it, and closing that gap takes about as long as reading this post.
What you actually have, right now, per plan tier
Supabase’s free plan has no automatic backups at all; Pro ($25/mo) keeps a rolling seven days of daily database backups, Team keeps fourteen, and the PITR add-on buys recovery to the second. No tier’s database backup includes Storage files, only their metadata.
Every row in that table is doing real work, and every row also has an edge that the settings page doesn’t state out loud. The backup gap is one of four conveniences that come due after launch; why everyone uses Supabase, and what the free tier really covers prices the other three. And if you are comparing hosts on what backups actually cost rather than what they advertise, what the Supabase alternatives cost you in backups puts the same plan-tier question to each of them.
What “backups are on” doesn’t cover
Three gaps sit underneath Supabase’s green backup toggle: Storage files are never in the database backup, the rolling seven-day window silently ages out anything older, and deleting the project deletes every backup with it. Each one lives on a different page of Supabase’s own docs, so checking the settings screen once catches none of them.
Storage files are not in the database backup
This holds on every plan. Supabase’s own documentation is direct about it: “database backups do not include objects you store via the Storage API, as the database only includes metadata about these objects.” Restore a database backup after losing a bucket and the storage.objects rows come back, complete with a path and a URL for every upload, pointing at files that no longer exist. An app that stores avatars, PDFs, or user uploads in a bucket needs a second, separate copy of those files. The database restore will look successful and be silently wrong.
The seven-day window only ever holds seven days
A daily backup on Pro ages out the moment an eighth one lands, so nothing before the current seven-day window is recoverable no matter when someone looks for it. A bad migration, a bug, or a bulk update that corrupts rows can sit unnoticed for longer than that during a quiet launch week, and by the time anyone checks, the backup that would have undone it is already gone.
Deleting the project deletes the backups with it
Supabase’s docs put this plainly: on deletion, “we permanently remove all associated data, including any backups stored in S3. This action is irreversible.” Pausing a project for nonpayment or inactivity and later deleting it to start fresh takes the safety net down with it. There’s no separate “keep the backups” option once the project itself is gone.
A backup that has never produced a working restore is a setting, not a safety net.
The restore drill, timed
A backup is a claim. The only way to check it is to spend it once, somewhere that doesn’t matter, before the day it does.
- 01 Spin up a second Supabase project, disposable for this one afternoon.
- 02 From the dashboard, restore your most recent daily backup (or a PITR point) into the new project. Note the start time.
- 03 Watch the dashboard for the completion notification. The project is inaccessible for the duration, so this step has real downtime attached, proportional to database size.
- 04 Note the finish time and write it down. That gap is your actual recovery time.
- 05 Run a row count on your three or four most important tables and compare it against production.
- 06 Try to open a file from a Storage bucket through the restored project. Confirm for yourself that the URL points at nothing, so the gap is felt once in a safe place instead of first in an incident.
- 07 Reset any custom Postgres role passwords. Daily backups don’t store them, so a restored project with custom roles needs new passwords before anything can connect as those roles.
- 08 Delete the throwaway project once you have written down the two numbers that matter: how long the restore took, and what did not come back.
That’s an afternoon of work. Run this drill once and the same two surprises show up almost every time: the restore takes longer than the dashboard’s spinner implies, and Storage comes back empty, because nobody until that moment realized it was never in the backup at all. Do it once, and the two numbers you’re left with, a real recovery time and a real list of what doesn’t survive, replace a setting you were trusting on faith.
Supabase point-in-time recovery, and the honest price of it
PITR replaces daily snapshots with continuous, second-level recovery: restore to the exact moment before a bad write instead of only to last night’s snapshot. The honest floor is roughly $130 a month on Pro once required compute is counted, not the $100 the add-on line suggests on its own. It earns that cost for a narrow case: an app with a high write volume, where losing anything since last night’s backup would mean losing real orders, messages, or transactions.
The price is worth stating in full, because Supabase’s pricing page understates it by quoting only one line item. Seven days of PITR retention is $100 a month, on top of the $25 Pro base. PITR also requires at least the Small compute add-on to keep the continuous archiving from falling behind: $15 a month on the list, of which Pro’s included $10 monthly compute credit covers most, leaving about $5. Add it up and that $130 floor is arithmetic, not an estimate. Fourteen days of retention runs $200 a month for the PITR line alone on the same compute floor; twenty-eight runs $400. Whether that’s worth it comes down to what a lost day would actually cost you. If losing everything since last night means re-entering a handful of orders you can reconstruct from payment records and email receipts, a well-tested daily backup covers the realistic loss window for a fraction of PITR’s price. If it means losing transactions no other system remembers, PITR is the honest answer. Either way, the restore drill above is what tells you whether “well-tested” is true yet. PITR stops being optional if the app stores health data: it is one of the four settings Supabase requires before a project counts as compliant, which is part of what the Supabase HIPAA add-on costs on the Team plan.
The free-plan path: backing up Supabase to GitHub
The free plan’s answer to “no automatic backups” is to run the equivalent yourself, and Supabase’s own upgrade guidance points at the same tool: “for smaller databases, we recommend taking a logical backup of the data using the pg_dump utility.” The direct connection, port 5432, is the one meant for this; the pooler’s transaction mode doesn’t support what pg_dump needs and will fail partway through.
pg_dump "postgresql://postgres:$DB_PASSWORD@db.<project-ref>.supabase.co:5432/postgres" \
--no-owner --format=custom --file="backup-$(date +%F).dump"Wrap that in a GitHub Action on a daily cron schedule, store DB_PASSWORD as a repository secret, and push the resulting file to a private artifact store or a separate private repo, never a public one. It won’t back up Storage either (no database backup does, per the section above), so pair it with whatever bucket-sync job matches your storage provider. This path depends on the cron job actually running and someone noticing if it stops, and it only ever restores to the last scheduled dump, never a specific second. Even with those limits, it’s a real, restorable copy sitting outside Supabase’s own infrastructure, on a plan whose settings page offers nothing at all in its place.
A restore drill run once against your actual schema is one of the checks a Beyond the Demo Audit runs before calling anything backed up, alongside the other data-loss patterns that show up across the same audits and the same one-database, no-staging setup that turns a bad migration into the incident a backup was supposed to undo.
For a faster read, the scorecard estimates nine of the twelve readiness areas from your answers and will tell you whether data safety is your weakest one before you ever touch a restore button. Whether any of this matters yet is really a question about whether the app is ready for real users to depend on in the first place. The backup you haven’t restored is a passed check sitting on top of an unrun test, and it’s the cheapest one on this list to finally run.
Common questions about Supabase backups
Does native backup cover Storage files?
No. On every plan, a Supabase database backup stores only the metadata rows for Storage objects, never the files. A restored project lists every upload with a working-looking URL that points at nothing. Files in buckets need their own copy, synced by a separate job.
How long does Supabase keep database backups?
Pro keeps a rolling seven days of daily backups, Team keeps fourteen, and the PITR add-on keeps whatever continuous window you pay for, starting at seven days. The free plan keeps nothing automatically; the only copy is one you make yourself.
Can I back up a Supabase project on the free plan?
Yes, by running pg_dump yourself on a schedule, over the direct connection on port 5432 rather than the pooler. A daily GitHub Action with the database password in a repository secret is the usual shape. It restores only to the last dump it took, never to a specific second.
Does deleting a Supabase project delete its backups?
Yes, immediately and irreversibly: Supabase removes all associated data on deletion, managed backups included. Download a final pg_dump and a copy of every bucket before deleting a project you might ever need to reconstruct.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
