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 July 2026.

What Supabase includes: daily backups on Pro

On the Pro plan ($25/month, as of July 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.
• 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.

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 July 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.

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 and Pro 250 GB per month; on Free, overage triggers a fair-use flow of notice, grace period, then restrictions — never a charge). Spend Cap is on by default on the Pro plan, and once the egress 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 andStorage files together, writes them to your own S3, R2, or B2 bucket — never ours — and then runs automated restore drills on your plan’s cadence (monthly on Solo, weekly on Team and Agency; 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 July 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.