Supabase backup: the complete picture
WHAT'S BUILT IN · WHERE THE GAPS ARE · HOW TO OWN YOUR COPY
Supabase is excellent at keeping your database running. Backing it up is a shared responsibility, and the split surprises people: what you get depends entirely on your plan, everything lives on Supabase's side of the fence, and nothing ever proves it restores. Here's the whole picture in one place — no scare tactics, just the map.
What Supabase gives you natively
- Free tier: no automated backups. Your database is the only copy of your data. A bad migration, a fat-fingered DELETE, or a paused project is unrecoverable unless you made a copy yourself.
- Pro: daily backups, about a week of retention. Solid for “the database broke yesterday.” Restoring rolls the entire project back to the snapshot — every write since is gone.
- Point-in-time recovery as a paid add-on. Much finer granularity, same structural property: it lives in the same platform and account as the database it protects.
The three gaps no plan closes
- Blast radius. Platform backups share fate with the platform: your account (billing lapse, compromised credentials, suspension), Supabase's infrastructure, and its retention window. An off-site copy in a bucket you own is the one backup that survives every failure mode that takes out the first two.
- No restore proof. A backup that has never been restored is a guess. Platform snapshots are almost certainly fine — but “almost certainly” is what incident reports are made of, and it's not an answer you can give an auditor asking “when did you last test a restore?”
- Migration-shaped disasters. The most common data loss isn't a crashed disk — it's a deploy. Daily granularity means a migration that goes wrong at 4:55 PM costs you the whole day, and a full-project rollback costs you the good writes too. (We wrote up exactly how that Friday goes, minute by minute.)
Your options, honestly
Native backups alone
- Zero setup, good defaults on Pro.
- Nothing on free tier.
- On-platform only; full-project restores; no restore testing.
- Fine if your data is replaceable or pre-revenue.
DIY pg_dump cron
- Free, works on every tier, you own the copies.
- You maintain credentials, encryption, retention, and monitoring forever.
- Fails silently — and nobody ever test-restores the dumps.
- Honest comparison: OffsiteDB vs a cron job.
Native + automated off-site
- Keep Supabase's backups on — they're good at platform-level recovery.
- Add encrypted snapshots to your own S3/R2/B2 bucket, on every tier.
- Every snapshot restore-drilled on real Postgres and row-counted.
- Tagged checkpoints before migrations; monthly restore-drill reports.
The detailed breakdown of what native backups do and don't cover is on Supabase native backups vs off-site backups.
Set it up: Supabase to a bucket you own
Each guide covers the Supabase-specific gotchas — which connection string works for pg_dump (the transaction-mode pooler doesn't), what a read-only backup role can see, and a one-command restore:
- Back up Supabase Postgres to Amazon S3
- Back up Supabase Postgres to Cloudflare R2
- Back up Supabase Postgres to Backblaze B2
- Back up Supabase Postgres to Wasabi
Building it yourself instead? The pg_dump command generator produces the right flags for Supabase, and the restore drill checklist is the part everyone skips.
Five minutes to a proven copy
Paste your Supabase connection string, point it at your bucket, and the first encrypted, restore-drilled snapshot runs in minutes. Start free, poke at the live demo, or see the restore-drill report you'd be forwarding to auditors.