Three ways to back up a Supabase database, and what each misses

Everyone building on Supabase eventually asks the same question, usually about a week after launch and usually at two in the morning: if I break something, can I get my data back?

The answer depends entirely on which of three routes you took, and each one misses something the other two cover.

Which one should I use?

Turn on whatever your Supabase plan gives you, and then keep a copy somewhere else. Those are two different jobs, and doing only the first is the mistake this article exists to prevent.

The dashboard backup protects you against your own mistakes. A copy you hold protects you against losing the account: a billing failure, a suspended project, a password you cannot recover. Those are different disasters and they need different answers.

What a backup actually contains

Your tables, your rows, your indexes and functions, and your Row Level Security rules (the policies that decide who can read what, not just the tables they apply to). That is the whole of it.

What it does not contain is everything that was never in the database:

The one that catches people is Storage. Every avatar, every uploaded PDF, every image your users added lives in object storage, not in the database. The database only holds the path to each file. Restore a database backup into an empty project and you get a table full of links to files that are not there.

Route 1: the Supabase dashboard

The easiest, and the one most people should turn on first. Supabase takes daily backups on paid plans, and point-in-time recovery is available as an add-on if you need to rewind to a specific minute rather than to last midnight.

What it is good at: it runs without you, it is complete, and restoring is a few clicks in a UI rather than a command you have to get right under pressure.

What it misses: the copy lives inside the account. If the project is suspended, the card on file fails, or you lose access to the login, the backups are behind the same door as the thing they were protecting. It is a fire escape inside the building.

It is also not available at all on the free plan, which is where most freshly-launched apps are sitting.

Which plan you are on decides whether you have this at all, and it takes two minutes to check.

Route 2: pg_dump on your own machine

Supabase is Postgres, so the standard Postgres tool works. pg_dump writes the whole database to a file you hold.

pg_dump "postgresql://…your connection string…" \
  --clean --if-exists --no-owner \
  --file backup-2026-08-09.sql

What it is good at: it is free, it is complete, the file is yours, and you can restore it into a brand-new project on a different account. Of the three routes this is the only one that survives losing everything else.

What it misses: it only happens when you remember. That is not a technicality, it is the whole failure. The dump on your laptop is dated from whenever you last thought about it, and the day you need it is never a day you were thinking about it.

There is a second, quieter problem: an untested dump is a guess. A file that was written while a migration was half-applied, or that silently truncated because the connection dropped, looks exactly like a good one until the day you try to use it.

Route 3: managed backups

Something else takes the copy on a schedule, stores it away from your account, and checks that the copy is real before calling it done. That last part is the one that actually matters.

That is what Reeve Care does: several copies a day depending on plan, encrypted and held outside your Supabase account, each one verified by counting what came out against what went in. A backup only counts as taken once it has been verified, which is why the date shown in the dashboard is the date of the last verified copy rather than the last attempt.

The honest trade-off: it costs money, and it is one more service in your stack. If you are disciplined enough to run route 2 on a real schedule and test the restores, you do not need it.

The whole cycle is drawn out on the Supabase backups page — the copy leaving Supabase, the check that follows it, and the button that puts it back.

Have you ever restored one?

That question decides whether you have a backup or a file that has never been opened. A dump nobody has read back is a guess about the future, and the moment you find out it was wrong is the moment you needed it to be right.

A restore test does not have to be dramatic. Make a new Supabase project, load your most recent backup into it, open the app against that project, and check that a row you recognise is there. Half an hour, once a quarter. If the restore fails, you have found out on a Tuesday afternoon instead of during an outage.

If you want the wider list of things worth checking on a newly launched app, the 10-minute security checklist covers backups alongside the rest, and the Supabase safety guide goes through what else is commonly left open.

What to do this week

Worth reading next: if you assumed your builder's undo covered your data, version history is not a backup is the one to read first. After that, your database is only as private as the keys in front of it, and which API keys are safe in your frontend covers the one that bypasses every rule you set.