Back up Neon, and prove it restores
Restore-tested backups of your Neon serverless Postgres, written to storage you control. Use the direct connection, keep scale-to-zero on, and every backup can prove it restores.
- Spin up a throwaway database
- Restore the backup
- Check the data came back 48 of 48 tables
- Delete the throwaway database
A second copy, outside Neon
An off-site backup is the one you can still reach when something goes wrong with the platform or the account. Norcube keeps it outside Neon, in storage you control, and proves it restores.
Off-site, in storage you control
Norcube runs a full pg_dump on your schedule and writes the encrypted archive to Norcube-managed storage in Frankfurt or to your own S3-compatible bucket.
Proven to restore
Every backup can be restore-tested: Norcube restores it into a throwaway database and confirms your schemas, tables and rows come back.
Yours, in a standard format
Download any backup and restore it with standard Postgres tools, independent of Norcube. No proprietary format, no lock-in.
Connect Neon, step by step
The Neon-specific settings, from the connection string to network access. Everything after that is the standard Protect form: schedule, retention and restore testing.
Open the Connect modal
Click Connect on your Neon Project Dashboard and select the branch, database and role you want to back up.
Turn off connection pooling
Disable the Connection pooling toggle. The host switches from the
-poolerendpoint to the direct compute endpoint, which is the onepg_dumpneeds.Copy the direct connection string
It looks like
postgresql://<role>:<password>@ep-cool-darkness-123456.eu-central-1.aws.neon.tech:5432/<database>?sslmode=require&channel_binding=require.Paste it into Norcube with SSL required
Choose Protect a database, pick PostgreSQL and paste the string. Neon requires SSL, so keep SSL mode on
require. You don't need a CA certificate.Allow Norcube's IP if you use IP Allow
A Neon database is publicly reachable with just the password by default. If you've turned on Neon's IP Allow, add Norcube's egress IP
18.196.207.101to the allowlist.
What Norcube adds
Restore testing
Prove each backup restores, not just that the dump ran. A Passed badge per backup and a restore-health score per database show recoverability at a glance.
Failure and missed-backup alerts
Get notified when a backup fails, a restore test can't confirm your data, or a schedule silently stops. By email, Slack or a signed webhook, on every plan.
Your own bucket
Keep backups in Norcube-managed storage in Frankfurt, or in your own Amazon S3, Cloudflare R2, Backblaze B2, Wasabi or MinIO bucket.
Standard archives
Every backup is a standard pg_dump archive, gzip-compressed by default. Download it any time.
Neon backups, answered
The questions that come up when backing up Neon. The full guide is in the docs.
Why not the pooled Neon connection?
-pooler) routes through PgBouncer in transaction mode, which is built for connection-per-request app traffic. pg_dump relies on session-level state, and Neon itself says to avoid pg_dump over a pooled connection. Use the direct host, without the -pooler suffix.Do I need to keep my Neon compute always on?
Why does a restore test mention the neon extension?
neon on every database, and you may have enabled Neon-only extensions like neon_utils or pg_session_jwt. They only run on Neon's compute and aren't your application data, so a restore test notes their absence as expected and still records a clean Passed.Is there anything to configure for Neon's SNI routing?
libpq and pg_dump, which send it correctly.Your Neon data, backed up and tested
Start on the Free plan. No credit card required. Connect Neon, pick a schedule and let the first restore test prove it.
- Free plan
- No credit card
- Standard formats
- Restore-tested