Supabase

Back up a Supabase database — send independent, restore-tested backups of your Supabase Postgres to storage you control. Which connection string to use, network access, and what restore tests do with Supabase's managed extensions.

To back up a Supabase database, Backup connects to its PostgreSQL like any other Postgres — Supabase runs real Postgres under the hood. Two Supabase specifics are worth knowing before you start: which connection string to use, and what a restore test does with Supabase's managed extensions.

Which connection string

Use the Session pooler connection — not the direct connection, and not the transaction pooler.

Direct (db.<ref>.supabase.co:5432) is IPv6-only unless you've bought Supabase's IPv4 add-on. Backup connects over IPv4, so it usually can't reach this host.
Transaction pooler (port 6543) is built for short-lived queries and doesn't work with pg_dump.
Session pooler (aws-0-<region>.pooler.supabase.com:5432) is IPv4 and dumps cleanly. This is the one to use.

Find the string

Open your project in the Supabase dashboard. The Connect button only shows on a project's pages, not on the organization overview.
Click the green Connect button in the project header.
Open the Direct connection (connection string) option.
Set Connection method to Session pooler.
Copy the string from the box below. It looks like:

postgresql://postgres.<project-ref>:[YOUR-PASSWORD]@aws-0-<region>.pooler.supabase.com:5432/postgres

Replace the literal [YOUR-PASSWORD] with your database password, set SSL mode to require, and paste it into Backup's credentials step.

Network access

A fresh Supabase project accepts the connection with just the password — no IP allow-listing needed. If you turn on Supabase Network Restrictions, add Backup's egress IP 18.196.207.101 to the allowed list (see network access).

Restore tests and Supabase's managed extensions

Every backup can be restore-tested: Backup restores it into a throwaway database and confirms your data comes back. Supabase preinstalls managed extensions — its secrets vault, and the pgsodium it builds on — that live only on Supabase's platform and can't run on a generic engine. Those aren't your application data; Supabase recreates them for you. So a restore test treats their absence as expected, notes them in the log, and still records a clean Passed. What it proves is what matters: your schemas, tables, and rows all restore. Details: Provider-managed extensions.

From there, it's the standard flow

Backup runs a full pg_dump on your schedule and writes the encrypted archive to storage you control. You can download any backup and restore it with standard Postgres tools, independent of Norcube — which is the point of an off-site copy.