Supabase gives you a real Postgres database with very little setup. That is the whole appeal. But when it comes to backups, two things are worth thinking about before you need them:
- Your backups live inside the same account as your database. Point-in-time recovery and the daily snapshots are Supabase’s, in Supabase’s storage, tied to your project. If you ever want a copy somewhere you control, on your own retention, in your own cloud account, that is on you.
- A backup that has never been restored is a guess. Almost every backup tool tells you the dump ran. Very few tell you the dump actually restores. Those are not the same thing, and you find out which one you have at the worst possible moment.
Norcube Backup addresses both. You point it at your Supabase database, backups land in a bucket you own, and every backup gets restore-tested into a throwaway database so you know it recovers. Here is how to set it up.
Connect your Supabase database
In the dashboard, choose Protect a database, pick PostgreSQL, and fill in a connection string. One detail matters for Supabase: use the Session pooler connection, not the direct connection.
- The direct connection (
db.<ref>.supabase.co) is IPv6-only unless you have paid for the IPv4 add-on, so a lot of clients cannot reach it. - The transaction pooler (port 6543) is optimized for short-lived queries and does not play nicely with
pg_dump. - The session pooler (
aws-0-<region>.pooler.supabase.com, port 5432) is IPv4 and works cleanly withpg_dump. This is the one to use.
To find it: click the green Connect button in your project header, open the Direct connection (connection string) option, set Connection method to Session pooler, and copy the string from the box below. It looks like postgresql://postgres.<ref>:[YOUR-PASSWORD]@aws-0-<region>.pooler.supabase.com:5432/postgres, so swap the literal [YOUR-PASSWORD] for your database password before saving. Set SSL mode to require and you are done. A fresh Supabase project accepts the connection with just the password. No IP allow-listing needed to get started.
Backups you own
From there, Norcube runs a full logical pg_dump of your database on your schedule and writes it to your storage. Bring your own S3 bucket and the encrypted dumps never sit in someone else’s account. Retention, region, and schedule are yours to set. You can pull any backup down whenever you want, straight from the CLI:
nrc backup download <job-id> --datasource <id> --file - | gunzip | pg_restore -d "$DSN"That last part is the point of independent backups: you can restore your data without us in the loop at all. It is a pg_dump archive in your bucket, and standard Postgres tools read it.
The part almost nobody does: prove it restores
Every Norcube backup can be restore-tested automatically. We spin up a disposable Postgres database, restore your backup into it, confirm the data came back, and tear the copy down. The database being backed up is never touched. The result rolls up into a restore-health score for each datasource, so “can we actually recover?” is a number you can look at, not a hope.
For Supabase specifically, one honest note. Supabase installs some managed extensions (like its secrets vault) that live on Supabase’s own platform and are recreated for you there. Those are not your application data, and a restore test flags them as expected-managed rather than as failures. What the restore test proves is the thing that matters: your schemas, your tables, your data all come back.
Backups are only real once you have restored one
If you run anything important on Supabase, an independent, restore-tested copy in your own storage is cheap insurance against the day the primary is gone, corrupted, or locked behind an account issue. Postgres and MongoDB are supported today, failure alerts are on in every plan, and restore testing is included, not an upsell.
You can try it on your own Supabase project in a few minutes, or read the step-by-step Supabase backup guide first.