What Neon's native backup doesn't cover

On Neon's Scale plan, with the history window set to its maximum, you can rewind a database to any moment in the last 30 days. You cannot rewind it to day 31. On Launch the edge is day 7, and on Free it is six hours ago. Those limits are part of what Neon's native backup doesn't cover, and they are the easy part to see.

The harder part is where all of it lives. Neon's history, its snapshots and the backup branch a restore leaves behind sit inside the same project, in the same account, as the data they protect. That is the right design for fast recovery. It is the wrong design for a backup that has to survive the account.

This article walks through six gaps in Neon's native recovery, how much each one matters, and what closes it. It also says plainly when you do not need to close any of them.

How Neon's native backup works, briefly

Neon separates compute from storage, and its storage layer keeps a history of write-ahead log (WAL) for each project. That history is what powers instant restore: you can rewind a root branch to any timestamp or LSN inside the history window. The window depends on your plan, from six hours on Free to a maximum of 30 days on Scale.

Two more tools sit on top of history:

• Snapshots are point-in-time captures of a root branch, kept inside the project. You can take them by hand, and on paid plans you can schedule them daily, weekly or monthly.
• Time Travel lets you run read-only queries against a past point in the history window before you commit to a restore.

Instant restore, snapshots and Time Travel are recovery tools, and they are genuinely fast. For the full mechanics, including how a restore picks its timestamp and what the backup branch is for, read how Neon's native backup works.

Here are the figures this article refers to. They come from Neon's history window documentation and plans page, checked on 2026-11-03.

Plan	History window (instant restore)	Manual snapshots	Scheduled snapshots
Free	6 hours, capped at 1 GB of changes	1	Not available
Launch	1 day default, up to 7 days	100	Daily, weekly or monthly, kept up to 35 days
Scale	1 day default, up to 30 days	100	Daily, weekly or monthly, kept up to 35 days

History is billed at $0.20/GB-month on paid plans, and snapshot storage at $0.09/GB-month.

The history window defaults to 1 day on Launch and Scale, not to the maximum. If you never changed it, your instant-restore reach is 24 hours, not 7 or 30 days. Check the setting before you rely on the number in the table.

What Neon's native backup doesn't cover, at a glance

Before the detail, the whole picture in one table. Every row gets its own section below.

Gap	What happens	Who it affects	How to close it
1. Same account	History, snapshots and backup branches go down together with the project or account	Every production project	A copy outside Neon, under separate credentials
2. Retention ceiling	Nothing scheduled survives past 35 days	Anyone with audit, legal or slow-to-surface data problems	Off-site backups with retention you set
3. No portable copy	No documented way to download a snapshot	Anyone who might move hosts or needs an archive	A pg_dump file you hold
4. Seven-day deletion window	A deleted project is gone for good after 7 days	Teams with many projects, automation or several admins	Off-site copy plus deletion guardrails
5. Restore overwrites	Instant restore rewinds every database on the branch	Anyone who needs one table back	Restore to a new branch, copy back
6. Object Storage and Functions	Not part of the database timeline	Projects using either product	Separate copies: Git for code, a bucket copy for objects

Gap 1: Everything lives in the same Neon account

This is the gap the other five grow out of. Instant restore reads from the project's history. Snapshots are stored in the project. The backup branch a restore creates, {branch_name}_old_{head_timestamp}, is another branch in the same project.

That is one blast radius. Anything that takes out the project or the account takes out the data and every recovery point for it at the same moment.

Four ways the blast radius goes off

None of them are exotic:

• Deletion. Neon's projects documentation says deleting a project "also deletes any computes, branches, databases, and roles that belong to the project." Snapshots and history go with it. Gap 4 covers the seven-day window you get afterwards.
• Compromised credentials. Deleting a project requires Admin access, "which every organization Admin has." Anyone who gets an admin's session, or an API key that can manage projects, can delete a project, and its recovery points go with it.
• Billing or account problems. If you lose access to the account for any reason, you lose access to the data and the recovery points together. They are not separate assets you can reach by another door.
• A provider-level incident. Your primary data and your recovery points run on the same provider's infrastructure. That is fine for a bad migration. It is not separation.

None of this is a criticism of Neon specifically. It is true of every managed database's native recovery: native features protect you against your own mistakes inside the account. They are not designed to protect you against the account.

The fix is not complicated. A logical backup with pg_dump, written to a bucket in a different account, sits outside the blast radius. Neon documents the command itself on its pg_dump backup page, and the walkthrough in how to back up a Neon database with pg_dump covers connection strings and versions in detail.

A minimal off-site version looks like this:

set -o pipefail
pg_dump -Fc -v -d "$NEON_UNPOOLED_URL" \
  | aws s3 cp - "s3://your-offsite-bucket/neon/$(date +%F).dump"

• -Fc writes Postgres's custom format, which pg_restore can restore selectively, table by table.
• $NEON_UNPOOLED_URL must be the unpooled connection string. Neon's docs are explicit that "pooled connections are not supported and will cause errors."
• set -o pipefail makes the pipeline fail when pg_dump fails. Without it, the exit status is the upload's, so a dump that dies halfway can still upload a truncated file and report success.
• The bucket should live in an AWS account, or with a provider, that your Neon credentials cannot touch. That is the point of the exercise.

Match your pg_dump client version to your project's Postgres version, as Neon's docs advise. For every other flag, our pg_dump and pg_restore guide has the full reference.

Give the backup job its own Postgres role and its own storage credentials, and keep the storage credentials out of the Neon console and your app's environment. If the same leaked secret can reach both the database and the backup bucket, the backup is not off-site in any sense that matters.

Gap 2: The retention ceiling

Neon's recovery reach has two hard edges, and both are short.

• The history window tops out at 30 days on Scale and 7 on Launch. Past that, instant restore and Time Travel cannot reach.
• Scheduled snapshots stop at 35 days. Neon's snapshot documentation puts it in one sentence: "Scheduled snapshots are kept for 35 days unless you set a shorter retention, and 35 days is also the maximum." Neon does keep the most recent scheduled snapshot while a schedule is active, even past its deadline, so you always have the latest one.

That ceiling holds for every frequency, including weekly and monthly. A weekly schedule keeps about five snapshots. A monthly schedule keeps one, or two for the few days after a new one lands, because the previous month's snapshot turns 35 days old and is deleted. Picking "monthly" does not give you a year of monthly backups. It gives you last month.

Thirty-five days sounds like a lot until you list the problems that surface slowly:

• A bug that has been writing wrong values to a column since last quarter.
• A customer asking what their record looked like before a change in March.
• An auditor asking you to show a backup from six months ago.
• A deletion nobody noticed until the monthly report ran.

Each of those needs a recovery point older than 35 days. On Neon's schedule, there isn't one.

The manual-snapshot workaround

Manual snapshots are the exception to the ceiling. Neon's docs say they "never expire unless you give them an expiration, which has no maximum." Paid plans allow 100 of them, Free allows 1.

So you can keep monthly or yearly recovery points on Neon, by taking a snapshot by hand on the first of every month. That works, with three costs worth naming:

• Someone has to remember. A retention policy that depends on a calendar reminder fails the month that person is on holiday.
• Each manual snapshot is billed as a full snapshot, per Neon's docs, at $0.09/GB-month. Twelve monthly snapshots of a large database are twelve full copies on your bill.
• They still live inside the project. Gap 1 applies to every one of them. A manual snapshot from last January is deleted with the project like everything else.

If you do keep manual snapshots for long-term retention, name them with the date and the reason ("2026-11-01-monthly"), and keep a list outside Neon of which ones exist. "Deleted snapshots cannot be recovered," in Neon's words, so an accidental cleanup of old snapshots is final.

The cleaner answer is to move long retention off Neon entirely: a scheduled pg_dump to storage you own, with a retention rule on the bucket (keep dailies for 30 days, monthlies for 12 months, yearlies for 7 years, or whatever your policy says). The schedule is yours, and the retention is a setting rather than a habit.

Gap 3: No portable copy

Neon's snapshot documentation describes creating snapshots, scheduling them, restoring from them and deleting them. It does not describe downloading or exporting one. A snapshot is a recovery point that only Neon can restore, into a Neon project.

That matters in three situations:

1. Moving to another Postgres host. If you leave Neon, or need a copy running on RDS, a self-hosted server or a laptop, a snapshot cannot help. You need a logical dump.
2. Archiving. An archive you cannot open without the original provider is a dependency, not an archive.
3. Inspecting old data offline. A .dump file can be listed with pg_restore --list and restored into any scratch database. A snapshot can only be restored back into Neon.

The only portable format is a pg_dump you run yourself. Neon's documented commands are short:

pg_dump -Fc -v -d "<unpooled_connection_string>" -f neon-backup.dump
pg_restore -v -d "<target_connection_string>" neon-backup.dump

The second command works against any Postgres, not just Neon. That is the whole property you are after. For choosing between custom, directory and plain formats, see our Postgres backup formats comparison.

Gap 4: Seven days after deleting a project, nothing is left

Neon's projects documentation is direct: "You can recover the project within seven days." And then: "After the recovery period ends, deletion is permanent."

Seven days is a real safety net. Recovery is a single CLI command or API call, and it costs nothing during the window: "There are no storage costs or recovery fees during the 7-day deletion recovery period."

neon projects list --recoverable-only
neon projects recover <project_id>

The first command lists projects still inside their recovery window. The second brings one back. The API equivalent is POST /projects/{project_id}/recover.

What recovery restores, and what it doesn't

Recovery is not a full undo. Here is what Neon's docs list on each side:

Comes back	Does not come back
All branches, endpoints, snapshots and compute configurations that existed at deletion	The Data API and its roles
Project settings such as IP Allow, logical replication and protected branches	The GitHub integration
Collaborators	Neon-managed and Vercel-managed Vercel integrations
Connection strings	Monitoring integrations
	Scoped Object Storage and AI Gateway credentials, which stay revoked
	Branches whose expiration time passed during the recovery window

The integration rows are the ones that bite. Your data comes back, your connection strings work again, and your deploy pipeline or monitoring is still disconnected until someone notices and re-enables it. Apps using scoped Object Storage credentials need new credentials too.

During the window, "You can't connect to a deleted project's databases." So a deleted project is an outage for as long as it takes someone to run the recover command.

Why seven days is shorter than it sounds

Seven days is plenty when a person deletes a project by accident and notices at once. It is short in the cases that don't announce themselves:

• A cleanup script deletes the wrong project on a Friday, and nobody looks at it until the following week.
• An attacker with admin access deletes a project and the account is not watched closely.
• A project nobody owns is deleted by mistake, and the team that needed it finds out three weeks later.

In all three, by day eight the project, its history and every snapshot are gone, and Neon cannot bring them back. Only a copy that lived outside the project survives, and restoring it is a plain pg_restore into a new project.

Neon lets you mark branches as protected, and project recovery restores that setting. It is a branch setting, and the seven-day rule for a deleted project still applies. Treat project deletion as an admin-only, reviewed action, and keep the number of organization Admins small.

Gap 5: A restore overwrites the branch

Instant restore is a rewind of the whole branch. Neon's instant restore documentation calls it "a complete overwrite of the database timeline, not a merge or refresh." Three consequences follow from that:

• Every database on the branch rewinds. "The operation applies to all databases on the branch, not just the one you are troubleshooting." If two services share a branch, restoring one restores both.
• Everything written since the restore point is gone from the branch. It is preserved in the backup branch, {branch_name}_old_{head_timestamp}, but your live branch no longer has it. That includes the neon_auth schema, which cannot be excluded.
• Connections drop briefly. "Existing connections to the selected branch are temporarily interrupted during the restore operation." Connection strings stay the same, so apps reconnect.

Instant restore also works on root branches only. Child branches cannot be restored this way.

Getting one table back

The common real-world case is not "rewind everything." It is "someone ran a bad UPDATE on the orders table at 14:02, and the rest of the database has had an hour of good writes since."

A full rewind would throw away that hour. The safer path is to restore the past state somewhere else and copy back only what you need:

1. Get the 14:01 state onto a separate branch, without touching the live one. A multi-step snapshot restore does this when a snapshot is close enough: Neon's snapshot docs describe it as creating a new branch from the snapshot and leaving the current branch unchanged.
2. Use Time Travel or a query against that branch to confirm the data is what you expect.
3. Dump the one table from the recovered branch with pg_dump -t orders, and restore it into the live branch.
4. Delete the temporary branch when you are done.

That is more work than one click, and it is the right trade when the rest of the database is fine. The exact commands, including the snapshot paths and how to verify the result, are in how to restore a Neon database.

An off-site dump has its own role in this case too. A -Fc dump lets you restore a single table directly with pg_restore -t, from any point in your retention, even one far older than the history window.

Gap 6: Object Storage and Functions are outside the database timeline

Neon now offers Object Storage and Functions alongside Postgres. Neither is part of the database's history. In Neon's words on the instant restore page: "Object Storage is not part of the database timeline, so a database restore does not revert its contents." The same page says the same applies to Functions.

So if a bad deploy deletes files from a bucket and corrupts rows at the same time, instant restore brings the rows back and leaves the files gone. The two get out of step: your database points at objects that no longer exist, or the other way around.

A pg_dump does not cover them either, and neither does our Neon backup, which is a Postgres backup. Be honest with yourself about what is in scope:

• Functions code should live in Git, deployed from there. Then the repository is the backup, and a redeploy is the restore.
• Object Storage contents need their own copy to a bucket you own, on their own schedule. Copy them with the tooling Neon documents for the product, to a bucket outside the project.
• Credentials for both should be documented somewhere outside the project. Gap 4 already showed that project recovery does not bring back scoped Object Storage credentials.

If you use neither product, this gap does not apply to you. Skip ahead.

When Neon's native recovery is enough

Not every project needs to close every gap. Some do not need to close any. Here is the honest version.

Neon's native recovery is enough on its own when losing the project would be an inconvenience, not an incident. That covers more projects than vendors of backup tools like to admit:

• A hobby project on Free. Six hours of history and one manual snapshot protect you against the realistic failure, which is your own bad migration. If the whole project vanished, you would rebuild it in an afternoon.
• Reproducible data. If your database can be rebuilt from seed scripts, migrations and an upstream source of truth, the database is a cache. Back up the scripts, in Git.
• Staging, preview and development branches. These exist to be thrown away. Instant restore and branching are exactly the right tools.
• Short-lived projects. A prototype or a one-off analysis that will be deleted next month has no retention requirement to meet.

Your situation	Native is enough?	Why
Hobby project, Free plan, data you could recreate	Yes	Losing it costs an afternoon
Staging or preview branches	Yes	Disposable by design
Data rebuilt from scripts or an upstream system	Yes	The scripts are the backup
Production app with customer data	No	Gaps 1 and 4: one blast radius, seven-day window
Customers, contracts or auditors ask for off-site backups	No	Native recovery points never leave the account
You need recovery points older than 35 days	No	Gap 2: the retention ceiling
You might move off Neon, or want an archive	No	Gap 3: no portable copy
You use Neon Object Storage or Functions	Partly	Gap 6: they need their own copies

If you landed in the top three rows, you can stop here. Keep an eye on the history window setting, take a manual snapshot before risky migrations, and get on with building.

If you landed lower, the rest of this article is the plan.

Why these gaps matter for SOC 2, ISO 27001 and GDPR

Compliance frameworks rarely say "use this backup product." They ask what you can show. For backups, auditors working to SOC 2 Type II, ISO 27001 and GDPR tend to look for the same three things, and native recovery struggles with all of them.

1. A copy stored separately from production

ISO 27001's Annex A includes an information backup control, and SOC 2's availability criteria cover backup and recovery. In practice, an auditor asks where your backups live. "In the same Neon project as the data" invites the follow-up about what happens if the project is deleted, and Gap 1 has no good answer.

2. A retention policy you can state and prove

Your policy might be "daily for 30 days, monthly for 12 months." Neon's scheduled snapshots stop at 35 days, so the monthly half of that policy is either manual snapshots taken by hand, or it is not met. A policy that relies on someone remembering is the kind of control auditors flag.

3. Evidence that restores work

GDPR Article 32 asks for "the ability to restore the availability and access to personal data in a timely manner," and for regular testing of the measures that do it. SOC 2 and ISO 27001 auditors ask for restore tests too. A dated restore test from an off-site backup is the evidence. "We could rewind the branch if we needed to" is not.

4. Retention that is not forever

GDPR adds a fourth point: retention cuts both ways. Keeping personal data in backups forever is its own problem, so whatever retention you set off-site should be deliberate and written down.

A complete backup checklist for a Neon project

Here is what a complete posture looks like for a production Neon project. Native covers the first block. The rest is on you.

Native recovery, set up properly

• History window set deliberately, not left at the 1-day default
• A manual snapshot taken before every risky migration
• Scheduled snapshots enabled on paid plans, with retention you chose
• Production branches marked as protected
• Everyone on the team knows instant restore overwrites every database on the branch

Off-site, outside the blast radius

• A scheduled pg_dump -Fc using the unpooled connection string
• Written to storage in a different account or provider, under separate credentials
• Retention set on that storage to match your written policy
• An alert when a backup run fails, sent somewhere a person will see it
• pg_dump client version matched to your Postgres version

Restore, tested

• A restore from an off-site dump into a scratch database, at least quarterly
• A single-table restore rehearsed, so the first one is not during an incident
• The date and result of each test written down, for the auditor and for you

Account and project hygiene

• Few organization Admins, and project deletion treated as a reviewed action
• A note of which integrations each project uses, so a recovered project can be rewired
• Functions code in Git, Object Storage contents copied separately, if you use either

The manual route to the off-site block, including a scheduled version with GitHub Actions, is in the pg_dump guide linked in Gap 1. If you would rather not maintain the script, automating Neon backups to your own storage walks through the managed setup step by step.

What to do next

Start with the check that costs nothing: open Settings > Postgres in your Neon project and look at the history window. If it still says 1 day, decide whether that is what you meant.

Then check where your most recent recovery point lives. If the answer is "inside the Neon project," you have a fast undo button and no backup in the sense that survives the account. Whether that is acceptable depends on which row of the decision table you landed in.

Gap 1 is the one SimpleBackups for Neon exists to close. We run scheduled pg_dump backups of your Neon databases to storage outside your Neon account, keep them for as long as your policy says, and alert you when a run fails. Gap 6 stays yours: we back up Postgres, not Object Storage or Functions.

Keep learning

• How to restore a PostgreSQL backup, for the pg_restore errors you are most likely to hit when restoring a dump onto a new host.
• The complete guide to PostgreSQL backup, for the Postgres-wide picture beyond Neon: tools, formats and restore strategy.
• The ultimate PostgreSQL database backup script, if you want a fuller DIY script than the one-liner above.

FAQ

---

This article is part of The complete guide to Neon backup: instant restore, snapshots, pg_dump, and the copy that lives outside Neon.