How to back up a Supabase project — every option compared

There are four real answers: the backups Supabase includes, the PITR add-on, doing it yourself with pg_dump, and a service like ours. Each covers different failure modes, and two gaps run through almost all of them. This guide lays out what each option actually protects, with working commands and prices as of August 2026.

What Supabase includes: daily backups on Pro

On the Pro plan ($25/month, as of August 2026) Supabase takes a daily backup of your database and keeps it for 7 days. You restore from the dashboard, in place. Three limits to be clear about:

• Database only. Storage files — user uploads, avatars, documents — are not in the backup.
• Usually not downloadable. Projects still on the older logical backup process can download backups from the dashboard — but projects on Postgres 15.8.1.079 or newer, and any project with PITR enabled, use physical backups, which cannot be downloaded. On the physical backup process, getting a copy you own means running pg_dump yourself — the .sql export guide has the exact commands.
• Daily granularity. A bad deploy at 5 pm can cost you everything since last night.

For a hobby project where losing a day is survivable, this is genuinely fine. It is the default for a reason. On the Free plan there are no automated backups at all — here is what that means in practice, and what to do about it.

How to download your Supabase backup

The follow-up question to “there is a daily backup” is always “can I have it?”, and the answer depends on machinery you did not choose. Open Database → Backups in the dashboard. If each backup has a download option next to it, your project is on the older logical backup process and you can take the file. If there is no download option, the project is on physical backups — Postgres 15.8.1.079 or newer, or any project with PITR enabled — and those restore in place but are not available for direct download, no setting or support request changes it.

Which means for most projects created recently, downloading a backup of your database is really making one: a logical dump you run yourself against the connection string, which you then own outright. That is the pg_dump command two sections down. The .sql export guide walks the dashboard check and the command in detail.

One nuance so the implication lands correctly. Physical backups are not a dead end inside Supabase: on paid plans the dashboard can restore one into a brand-new project, Auth users included. What they cannot do is leave — there is no file to hold, archive, or replay somewhere that is not Supabase. For a copy that survives an account problem or moves to another host, it still has to be one you made.

The PITR add-on: $100/month per project

Point-in-Time Recovery costs $100/month per project for each 7-day retention window (as of August 2026). In exchange you get second-level recovery points: roll the database back to 14:03:27, right before the bad migration ran. If you need minute-level RPO — a production app where losing even an hour of writes is unacceptable — PITR is the right choice, and nothing else in this guide replaces it.

It is still database only, still lives on Supabase infrastructure, and the price is per project — three projects with PITR is $300/month. We wrote a separate honest comparison of PITR and BackupDrill, including where PITR wins outright.

DIY: pg_dump to storage you own

The classic answer, and a good one if you maintain it. Grab the Session pooler connection string from the Connect button at the top of the dashboard. Do not use the Direct connection string — it runs over IPv6 unless the project has the paid IPv4 add-on, and fails with a network error on IPv4-only networks, which is the single most common DIY backup failure.

# Session pooler string — Connect button at the top of the dashboard
export DB_URL="postgresql://postgres.<project-ref>:<password>@aws-0-<region>.pooler.supabase.com:5432/postgres"

pg_dump "$DB_URL" \
  --format=custom \
  --schema=public \
  --file="backup-$(date +%F).dump"

Note the --schema=public: this captures your application schema only. Supabase-managed schemas — auth (your users), storage (file metadata) — are not included, and dumping them as a non-superuser is restricted. Know what your backup does and does not contain before you need it.

That single command is the backup case. One trap worth knowing if you reach for the official CLI instead: the default supabase db dump output contains no rows — schema definitions only. The .sql export guide covers both commands and that trap in detail. If what you want is a one-off export rather than a backup — schema without rows, rows without schema, custom roles, or a copy destined for a different project — the flags differ for each and the export guide has the full parameter set and the clone-to-a-new-project path.

Two things bite people here:

• Version skew. Your pg_dumpmajor version must be ≥ the server’s — Supabase runs PG 15 or 17. Check pg_dump --version against select version(); an older client refuses to dump a newer server.
• Use the postgres pooler user. A plain read-only role errors on RLS-enabled tables and misses sequence grants, so the dump dies partway or restores incomplete.

The egress bill nobody mentions

Every backup pulls your data out of Supabase, and that is uncached egress: $0.09/GB beyond your plan’s allowance (Free 5 GB, Pro 250 GB per month; Free overage triggers fair-use restrictions, never a charge). Spend Cap is on by default on Pro: once the quota is exhausted, further egress is blocked until the next billing cycle — your app’s traffic included, not just the backup’s. In practice: a weekly backup of a 10 GB project is roughly free; a daily backup of a 50 GB project is about $112/month — more than PITR. Size × frequency decides everything; the CLI docs include an estimate command that projects your number before you schedule anything.

And after the dump succeeds you still have to schedule it — the GitHub Actions guide walks through a complete weekly workflow — ship it to storage you control (our bucket setup guide covers R2, S3, and B2), rotate old copies, and test restores.

The two gaps in all of the above

Gap one: Storage files. A database restore — built-in, PITR, or pg_dump — only brings back the storage.objects table, which is metadata. The actual files live in a separate S3 backend, so the restored database points at files that may no longer exist. Every URL resolves to a 404 while every SQL query looks healthy. We wrote up the full mechanics and the fix.

Gap two: verification. None of these options ever restores your backup to check it works. A backup you have never restored is a guess — dumps taken with the wrong role, a mismatched pg_dump version, or a half-failed job all look like success until the day you need them. The test is cheap and nothing here runs it for you, so we wrote up how to test that your backup actually restores — by hand in fifteen minutes, or automated.

Where BackupDrill fits

BackupDrill is built around those two gaps. It takes scheduled backups of the database and, once you add its S3 keys, your Storage files, writes them to your own S3, R2, or B2 bucket — never ours — and then runs automated restore drills on your plan’s cadence (weekly on every paid plan; Free gets one drill on its first backup): the latest snapshot is restored into a throwaway Postgres and verified — archive sha256, pg_restore completes, post-data objects (indexes, constraints, triggers) present, table count matches the manifest, no missing tables, populated tables non-empty. If a drill fails, you get an email — before you need the backup, not after. Weighing other hosted backup services? We compared SimpleBackups and BackupDrill honestly, including where they win.

The free plan covers one project with weekly backups; paid plans are $19, $49, and $99/month (as of August 2026). The backup engine itself is open source (MIT) at github.com/backupdrill/cli, so nothing about the format locks you in — restores work with stock pg_restore, with or without us. Start with the quickstart, or read the restore & recovery guide first if you want to see the bad-day path before committing.

Which should you pick

These combine. PITR plus BackupDrill is a legitimate setup: PITR for recovery granularity, BackupDrill for off-platform copies, Storage files, and proof that restores work.

FAQ