Neon

To back up a Neon database, Backup connects to its PostgreSQL like any other Postgres. Neon runs real Postgres under the hood. A few Neon specifics are worth knowing before you start: which connection string to use, how network access and auto-suspend behave, and what a restore test does with Neon's managed extensions.

Which connection string

Use the direct (unpooled) connection string, not the pooled one.

• Pooled (ep-<id>-pooler.<region>.aws.neon.tech) routes through Neon's PgBouncer in transaction mode. It's built for serverless, connection-per-request app traffic and doesn't work with pg_dump, which relies on session-level state. Neon says this explicitly: avoid pg_dump over a pooled connection.
• Direct (ep-<id>.<region>.aws.neon.tech, no -pooler) is the plain compute endpoint. This is the one pg_dump needs, and the one to give Backup.

Both use port 5432. The only difference in the host is the -pooler suffix.

Find the connection details

1. Click Connect on your Neon Project Dashboard to open the Connect to your database modal.
2. Select the branch, database, and role you want to back up.
3. Disable the Connection pooling toggle. This switches the host from the -pooler endpoint to the direct one.
4. Copy the string. It looks like:

postgresql://<role>:<password>@ep-cool-darkness-123456.eu-central-1.aws.neon.tech:5432/<database>?sslmode=require&channel_binding=require

Neon requires SSL, so keep SSL mode set to require when you paste this into Backup's credentials step. sslmode=require is what works; you don't need to supply a CA certificate.

One Neon detail behind the scenes: Neon routes to your compute by SNI (the hostname in the TLS handshake), not by IP. Backup connects with modern libpq/pg_dump, which sends SNI correctly, so this is transparent and there's nothing to configure.

Network access

By default a Neon database is publicly reachable with just the password, so no allow-listing is needed. If you turn on Neon's IP Allow (a Scale-plan feature that restricts connections to trusted addresses), add Backup's egress IP 18.196.207.101 to the allowlist, or Neon will refuse the connection. See network access.

Neon also auto-suspends idle computes (scale-to-zero, after five minutes of inactivity by default). When Backup connects to a suspended compute, Neon wakes it automatically. The first connection of a run may take a few hundred milliseconds longer while the compute activates. This is normal and Backup handles it; you don't need to keep the compute always-on.

Restore tests and managed extensions

Every backup can be restore-tested: Backup restores it into a throwaway vanilla Postgres and confirms your data comes back. Neon preinstalls its own platform extension, neon, which is loaded on every Neon database and exists only on Neon's compute. If you've also enabled neon_utils (its num_cpus() autoscaling helper) or other Neon-only extensions like pg_session_jwt, those live on Neon's platform too. None of them run on a generic engine.

Those aren't your application data. 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. To get started, connect a database.