How to back up Supabase Postgres to Backblaze B2
RESTORE-TESTED · ENCRYPTED · IN A BUCKET YOU OWN
Supabase keeps your database running, but its snapshots live in the same account and region as the database itself. An off-site copy in your own Backblaze B2 bucket protects you from the failures the platform can't: a bad migration, a locked account, or a compliance question you need a real answer to. Here's how to set it up in a few minutes — and, crucially, how to know the backup actually restores.
Step 1 — Get your Supabase connection string
Supabase dashboard → Project Settings → Database → Connection string. Choose the URI tab.
Use the direct connection or the session-mode pooler (port 5432). Do not use the transaction-mode pooler (port 6543) — it doesn't support the session state pg_dump needs, and your backup will fail. If your network is IPv4-only and the direct host won't resolve, the session pooler is the reliable choice.
A read-only role is all you need. The exact CREATE ROLE SQL is on the security page.
Step 2 — Create a Backblaze B2 bucket and access keys
- In Backblaze, create a B2 bucket (set it private).
- Create an Application Key limited to that bucket.
- Copy the keyID, applicationKey, and the S3-compatible endpoint shown for your bucket.
Create an Application Key scoped to the bucket. B2's S3-compatible API uses the keyID as the access key ID and the applicationKey as the secret. B2 is one of the cheapest durable stores available.
Endpoint: https://s3.<region>.backblazeb2.com Region: your bucket's region, e.g. us-west-004 Bucket: your-backup-bucket
Step 3 — Connect it to OffsiteDB
Paste the Supabase connection string, add Backblaze B2 as your destination with the bucket and keys from Step 2, and choose a schedule (hourly to daily). OffsiteDB tests the connection, then runs pg_dump, gzips and seals the artifact with AES-256-GCM, and ships it to your bucket. The public schema holds your application data. The auth and storage schemas are managed by Supabase and aren't readable by a normal role — include them only if you connect with your full postgres credentials.
Step 4 — Know it restores (the part everyone skips)
Every snapshot is restore-drilled: OffsiteDB restores it into a throwaway Postgres cluster and counts the rows before marking it sealed. When you need it back, every artifact is a standard custom-format dump:
gunzip -c supabase-db_2026-06-09.dump.gz \ | pg_restore -d "$NEW_DATABASE_URL" --clean --if-exists
You also get a monthly Restore Drill Report with tested restore times — the document you forward when someone asks “are your backups tested?”
Before your next migration
Scheduled snapshots cover the slow disasters; deploys are the fast ones. One step in CI seals a tagged, restore-drilled checkpoint seconds before each migration runs — so a bad ALTER TABLE costs you a revert, not a day of data. Here's how that Friday goes with and without one.
FAQ
Does this work with Supabase's free tier?
What permissions does the backup need on Supabase?
Where exactly does my data end up?
Can I just run pg_dump in a cron job instead?
Related guides
- Back up Supabase Postgres to Amazon S3
- Back up Supabase Postgres to Cloudflare R2
- Back up Supabase Postgres to Wasabi
- Back up Neon Postgres to Backblaze B2
- Back up Railway Postgres to Backblaze B2
Keep reading
- Supabase backup: the complete picture — what the platform includes natively and where the gaps are
- OffsiteDB vs a cron job running pg_dump — the honest comparison
- Anatomy of a bad migration — minute by minute, with and without a checkpoint