GUIDES / NEONWASABI

How to back up Neon Postgres to Wasabi

RESTORE-TESTED · ENCRYPTED · IN A BUCKET YOU OWN

Neon 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 Wasabi 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 Neon connection string

Neon Console → your project → Dashboard → Connection Details.

Neon gives you a pooled and a direct (unpooled) connection string. Use the direct endpoint for backups — the pooled endpoint runs PgBouncer in transaction mode, which pg_dump can't use. Neon requires SSL, so keep ?sslmode=require on the URL.

A read-only role is all you need. The exact CREATE ROLE SQL is on the security page.

Step 2 — Create a Wasabi bucket and access keys

  1. In the Wasabi console, create a bucket (keep it private).
  2. Create an access key pair under Access Keys.
  3. Copy the access key, secret key, and the regional endpoint for your bucket.

Create an access key in the Wasabi console. Wasabi is fully S3-compatible with flat pricing and no egress fees.

Endpoint: https://s3.<region>.wasabisys.com
Region:   your bucket's region, e.g. us-east-1
Bucket:   your-backup-bucket

Step 3 — Connect it to OffsiteDB

Paste the Neon connection string, add Wasabi 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. A read-only role scoped to your application schemas captures everything you need; Neon imposes no special hidden schemas.

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 neon-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?”

FAQ

Does this work with Neon's free tier?
Yes. OffsiteDB connects with any standard Neon connection string regardless of tier. Neon Postgres runs Postgres 16, which is fully supported.
What permissions does the backup need on Neon?
A read-only role is enough — OffsiteDB only ever runs pg_dump and never needs write access. A read-only role scoped to your application schemas captures everything you need; Neon imposes no special hidden schemas.
Where exactly does my data end up?
In your own Wasabi bucket, encrypted with AES-256-GCM before it leaves the backup worker. OffsiteDB never holds the only copy — if you ever leave, your backups are standard pg_dump archives you can restore without us.
Can I just run pg_dump in a cron job instead?
You can — but a cron job doesn't prove the dump restores, alert you when it silently stops, or hand you a tested-restore report for a security review. OffsiteDB restore-drills every snapshot into a real Postgres cluster, which is the part that matters when you actually need it.

Related guides