COMPARE / SUPABASE NATIVE ↔ OFF-SITE

Supabase native backups vs off-site backups

AN HONEST COMPARISON — KEEP BOTH, FOR DIFFERENT RISKS

Supabase's built-in backups are useful and you should leave them on. This page isn't a takedown — it's a map of which risks each layer actually covers, so you can decide what your data justifies. The short version: native backups recover the platform's failures; off-site backups recover yours.

What native backups do well

Where the line is

Native backups can't

  • Cover the free tier — there are no automated backups there at all.
  • Survive account-level failure: billing lapse, credential compromise, suspension.
  • Leave the platform — you can't point them at your own bucket.
  • Restore selectively from a daily snapshot — it's the whole project or nothing.
  • Prove they restore — no drill, no row counts, no evidence for an audit.
  • Reach back past the retention window.

Off-site restore-tested backups add

  • Coverage on every tier, free included.
  • Copies in your S3/R2/B2 bucket — outside the account and blast radius.
  • Every snapshot restore-drilled on real Postgres and row-counted before it's sealed.
  • Tagged checkpoints seconds before each migration — restore just the damaged tables.
  • Retention you set: 30, 90, 365 days.
  • A monthly restore-drill report you can hand to an auditor or a customer.

The honest decision rule

If your project is pre-revenue and the data is replaceable, native backups on Pro are probably enough — and on the free tier, anything automated beats nothing, even a cron job. The moment real customers depend on the data, or someone asks you to prove recoverability, you need a copy that lives outside the platform and a restore that's already been tested. That's the layer OffsiteDB is.

The full picture of Supabase's backup options is on the Supabase backup guide; the setup itself takes about five minutes — Supabase → S3 or Supabase → R2.

Add the off-site layerSee a restore-drill report

FAQ

Should I turn off Supabase backups if I use OffsiteDB?
No — keep them. Native backups are the fastest path for platform-level recovery, and they cost you nothing extra on Pro. Off-site copies are a second, independent layer, not a replacement.
Is this just vendor lock-in fear-mongering?
The risk isn't that Supabase disappears — it's mundane things: a billing lapse pausing a project, a compromised account, needing data past the retention window, or an auditor asking for restore evidence. Off-site copies answer those; on-platform backups structurally can't.
What does 'restore-tested' actually mean?
Every OffsiteDB snapshot is restored into a throwaway real Postgres cluster and row-counted before it's marked sealed. The ledger entry says 'proven: 184 tables, 9.2M rows' — not 'uploaded'. That's the difference between having files and having restores.
Does OffsiteDB replace point-in-time recovery?
No. PITR gives you fine-grained rollback within its window and is great if you can budget for it. OffsiteDB gives you scheduled and pre-migration snapshots that live outside the platform and prove they restore. Teams that care most about migrations use tagged checkpoints rather than PITR.