The complete guide to Neon backup

Neon keeps a history of every change for a window that depends on your plan: 6 hours on Free, up to 7 days on Launch and up to 30 days on Scale. Inside that window you can restore a root branch to any second, which Neon calls instant restore. Paid plans can also schedule snapshots kept for up to 35 days. All of it lives inside your Neon project, so it is recovery, not an off-site backup.

It is point-in-time recovery, and a very good one, but it is not an independent copy. The history it restores from sits in the same Neon project as the data. If the project is deleted, the account is locked or the history window has rolled past the moment you need, instant restore cannot help. A backup is a copy stored somewhere the original can't take down with it.

The history window defaults to 6 hours on Free, capped at 1 GB of changes, and to 1 day on paid plans. You can raise it to 7 days on Launch and 30 days on Scale. Longer windows cost more, because Neon bills retained history at $0.20 per GB-month. Anything older than the window is gone from instant restore.

Neon's documentation describes no way to download or export a snapshot. Snapshots are restored inside Neon. If you need a file you can keep, move or restore into another Postgres provider, run pg_dump against the unpooled connection string and store the output somewhere you control.

A deleted Neon project, with its branches and snapshots, can be recovered for 7 days through the CLI or API. After that the deletion is permanent and nothing in the project survives, including its history and snapshots. Integrations such as Vercel, GitHub and the Data API have to be reconnected even after a successful recovery.

Copy the connection string from the Neon Console with connection pooling turned off, then run pg_dump -Fc -v -d with that string and -f with an output filename. Neon's docs warn that pooled connections cause errors. Use a pg_dump version that matches your project's Postgres version, and send the file to storage outside Neon.

At most 35 days, whatever the frequency. Backup schedules run daily, weekly or monthly on paid plans, and retention is set per schedule, from 1 hour up to that 35-day ceiling. Neon keeps the most recent scheduled snapshot while the schedule stays active, so you never drop to zero. Manual snapshots are the exception: they never expire unless you set an expiry, but they are capped at 100 per project on paid plans and 1 on Free.

No. The 35-day ceiling applies to monthly schedules too, so each monthly snapshot is deleted about five days after the next one arrives. At any time you hold the latest month, and two snapshots only briefly. A weekly schedule holds about five snapshots and a daily one about 35. Combining frequencies, which the CLI and API allow, still stops at 35 days. A year of monthly restore points means taking manual snapshots yourself, or keeping pg_dump copies outside Neon.

Only from a logical backup. Instant restore and snapshots restore inside Neon. A pg_dump file in custom format restores into any Postgres host with pg_restore, as long as the target runs the same or a newer major version. This portability is the main reason to keep pg_dump backups alongside Neon's native recovery.