How Neon native backup works: instant restore, snapshots and the history window

On Neon's Scale plan, with the history window at its maximum, you can rewind a production branch to any timestamp in the last 30 days, and Neon's docs say the restore typically takes a few seconds. That is a better recovery story than most teams would build for themselves. This guide explains how Neon native backup works, feature by feature, because the part people get wrong is not whether it works. It is what a restore rewrites, and where the thing you restore from actually lives.

By the end you will know what each of Neon's four recovery features restores, how far back it reaches on your plan, and which one to reach for when something breaks.

How Neon native backup works, in one table

Neon gives you four recovery tools. They overlap, and they all depend on the same underlying mechanism, which we cover near the end. Here is the whole picture first.

Feature	What it restores	How far back	Where it lives	Plan
Instant restore	A whole root branch, every database on it, to a timestamp or LSN	Your history window: 6 hours to 30 days	WAL history inside the project	All plans
Time Travel	Nothing. Read-only queries against a past point	Your history window	A temporary branch inside the project	All plans
Manual snapshots	A root branch, to the moment the snapshot was taken	Until you delete it, or until its expiry	Inside the project	1 on Free, 100 on paid
Scheduled snapshots	A root branch, to the moment the scheduled snapshot ran	Up to 35 days	Inside the project	Paid plans only

Two things stand out. Every feature works on root branches, and every feature keeps its data inside the same Neon project. Hold on to the second one. It is the subject of the last section.

The history window: what Neon keeps and for how long

Neon separates compute from storage. The storage layer keeps a history of write-ahead log (WAL) changes for each project, and that history is what lets you restore, query or branch from a past point. The length of history Neon keeps is the history window.

The window is set per project, not per branch. Neon's history window documentation puts it plainly: "Changing the history window affects all branches in your project."

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

The figures come from Neon's plans page and the history window docs. On Free, history costs nothing but stops at 1 GB. On Launch and Scale it is billed as storage at $0.20/GB-month, so a longer window on a write-heavy database costs real money.

You change the window in the Console under Settings > Postgres with the History window slider, or through the project API with the history_retention_seconds property. Setting it to zero is allowed, and the docs are clear about the trade: it "disables instant restore and Time Travel queries."

The default on paid plans is 1 day, not the maximum. If you upgraded to Scale for the 30-day window and never moved the slider, you have 1 day. Check Settings > Postgres before you need it.

Instant restore: what a restore actually rewrites

Instant restore is Neon's point-in-time restore. You pick a root branch and a timestamp or LSN inside the history window, and Neon moves the branch back to that point. The instant restore docs are precise about what that means, and every detail matters during an incident.

• It works on root branches only. A project starts with a root branch called main. Branches you create from it are child branches, and instant restore does not support them. If your production database sits on a child branch, this feature is not available to you on that branch.
• It overwrites, it does not merge. Neon's words: a restore "is a complete overwrite of the database timeline, not a merge or refresh." Every change made after the restore point is gone from the branch.
• It covers every database on the branch. If the branch holds an app database and an analytics database and you restore to fix app, both go back. The restore also replaces Managed Better Auth data in the neon_auth schema, and the docs say there is no way to exclude it.

It saves the old state first. Before overwriting, Neon keeps the branch's previous state as a backup branch named {branch_name}_old_{head_timestamp}. The restored branch and the backup branch then become two separate root branches.

The backup branch name looks like this (illustrative timestamp):

main_old_2026-11-04T14:02:00Z

That branch is your undo button. To reverse a restore, you restore again and pick the backup branch as the source. It also consumes storage until you delete it, from the Branches page. A backup branch created when restoring from another branch cannot be deleted, so you drop its databases or tables instead if you want the space back.

Connections drop briefly. Existing connections to the branch are interrupted during the restore. Your connection string does not change, so applications reconnect once it finishes.

Some things are outside the timeline. "Object Storage is not part of the database timeline, so a database restore does not revert its contents." Functions are not reverted either. If a bad deploy wrote rows and uploaded files, a restore fixes the rows and leaves the files.

Running a restore from the CLI

In the Console, the path is Backup & Restore > Restore from history, then the From history tab. From the terminal, the command is neon branches restore. To restore main to a point in its own history:

neon branches restore main ^self@2026-11-04T13:55:00Z \
  --preserve-under-name main_before_restore

^self means "this branch's own history", and @ sets the point. On the CLI, --preserve-under-name is required when you restore to ^self: it names the backup branch Neon keeps, instead of the default _old_ name. Add --project-id if your CLI context spans several projects.

To restore to an exact WAL position instead of a timestamp, pass an LSN after the @. This example, from Neon's docs, restores development from another root branch at an LSN:

neon branches restore development production@0/12345

The same @ syntax accepts an LSN against ^self. An LSN is useful when you have pulled the exact position of the bad transaction from logs, and a timestamp would be a guess either side of it.

If you automate incident tooling, the API equivalent is a POST to /projects/{project_id}/branches/{branch_id}/restore with source_branch_id, source_timestamp and preserve_under_name in the body. The step-by-step incident version of all this, including recovering a single table without rewinding the whole branch, is in our guide to restoring a Neon database.

Instant restore is not supported on a branch that was itself created by a snapshot restore. If you restored from a snapshot recently and then try a point-in-time restore, Neon returns restore from snapshot on target branch is still ongoing.

Time Travel: look before you restore

Because a restore overwrites everything after the restore point, picking the wrong point costs you twice. Time Travel lets you check first. It runs read-only queries against any point inside the history window, without touching the branch.

Under the hood, Neon spins up a temporary branch and compute at the time you select. Per the Time Travel docs, "After 30 seconds of inactivity, the timeline is deleted and the endpoint is removed." The compute does not appear on your Branches page, though its create and delete events show up under Operations.

You can use it from the SQL Editor with the Time Travel toggle, from the built-in editor under Restore from history, or from the CLI:

neon connection-string main@2026-11-04T13:55:00Z --psql

That opens a psql session against main as it was at 13:55. Run the query that tells you whether the data is still intact, for example a SELECT count(*) on the table that lost rows, then move the timestamp until you find the last good moment.

Two limits apply. Queries must be read-only, and Object Storage, Functions and AI Gateway configuration cannot be queried historically. The temporary compute also counts toward your consumption for the billing period, so a long investigation is not free.

Pin the timestamp you verified in Time Travel and paste that exact value into the restore command. Restoring to "about 13:55" after checking 13:55:00 is how teams land one bad transaction too late.

Snapshots and backup schedules

History is continuous but short. Snapshots are the opposite: a fixed capture of a root branch at one point in time, kept for longer. Neon's snapshots and backup schedules docs describe two kinds.

	Manual snapshots	Scheduled snapshots
Created by	You, on demand	A backup schedule
Limit	1 on Free, 100 on paid plans	Not counted toward the manual limit
Frequency	Whenever you take one	Daily, weekly or monthly, at an hour you choose
Retention	Never expire, unless you set an expiry	1 hour to 35 days, 35 days by default and at most
Plans	All	Paid plans only
Billing	Full size, $0.09/GB-month	First at full size, then incremental, $0.09/GB-month

Schedules apply to root branches only. While a schedule is active, Neon keeps the most recent scheduled snapshot even after its retention deadline passes, so a schedule never leaves you with zero.

The 35-day ceiling is the number to plan around. If an auditor asks for 90 days or a year of history, a backup schedule cannot produce it. Manual snapshots can be kept longer, but someone has to take each one by hand, and the paid-plan limit is 100.

What 35 days means for daily, weekly and monthly schedules

The ceiling applies to every frequency, which is easy to miss. Retention is set per schedule, and whichever frequency you pick, no scheduled snapshot outlives 35 days. Here is what each one leaves you with at the maximum retention:

Schedule	Retention	Snapshots you hold at any time	Oldest restore point
Daily	35 days	About 35, one per day	35 days ago
Weekly	35 days	About 5, one per week	5 weeks ago
Monthly	35 days	1, and 2 for a few days after each new one	About a month ago

A monthly schedule is the one that surprises people. Say it runs on the 1st. On 1 April, March's snapshot is 31 days old and April's arrives, so you hold two. Around 5 April, March's snapshot reaches 35 days and is deleted. From then until 1 May you hold one. A monthly schedule never builds up a year of monthly restore points. It keeps the latest month.

You can combine frequencies, but only through the CLI or API: the Console offers one frequency per branch. Neon's own example pairs a daily and a weekly schedule, each entry with its own retention:

neon snapshots schedule set --branch main \
  --schedule '[{"frequency":"daily","hour":3},{"frequency":"weekly","day":1,"hour":4}]'

A combined schedule gives you dense recent points and a few older ones, inside the same 35 days. It does not extend history past them. Neon's docs show daily plus weekly and do not say whether all three frequencies can run together.

Restoring from a snapshot comes in two shapes:

• One-step restore writes the snapshot into the existing branch. The branch name and connection string stay the same, the branch ID changes, and Neon keeps the previous state as a backup branch named <branch_name> (old).
• Multi-step restore creates a new branch from the snapshot and leaves your current branch alone. You inspect the data, then finalize to swap it in.

Multi-step is the safer default during an incident, because nothing is overwritten until you decide it should be.

Branching is not a backup, but it is how all of this works

Every feature above sits on one mechanism: Neon branching. Neon's branching docs describe a branch as "a copy-on-write clone of your data," where "Writes to a branch are saved as a delta." Creating a branch does not physically duplicate the database and does not load the parent.

That design is why instant restore can finish in seconds. The history is already in Neon's storage, so there is no dump to replay into a fresh server, and the old state becomes the backup branch. Time Travel is a short-lived branch at a past moment. A snapshot restore is a branch created from a captured state.

It is also why a branch is not a backup. A branch shares storage and history with its parent inside the same project. Creating a pre-migration branch before a risky change is a good habit, and it gives you a fast way back from that change. It does not give you a second copy anywhere else.

What lives where: the one-line answer

History, Time Travel, snapshots and backup branches all live inside the same Neon project as the data they protect. That is the honest one-line answer to "where are my Neon backups." It matters most in the failure modes that take the project with them: a deleted project, which Neon lets you recover for seven days and then deletes permanently, a compromised account, or a billing problem. We walk through each of those, and what to do about them, in what Neon's native backup doesn't cover.

What to do next

Tonight, open Settings > Postgres and check your history window. If it still says 1 day on a paid plan, decide whether that is enough to notice a problem before the evidence ages out. Then set a daily backup schedule on your production root branch. The first scheduled snapshot is billed at full size, and the ones after it only for incremental storage.

After that, take one copy outside Neon. The native way is pg_dump against your unpooled connection string, covered step by step in how to back up a Neon database with pg_dump. If you would rather not run that by hand, automating Neon backups to your own storage shows the scheduled version.

Instant restore stays your first move after a bad migration; nothing we sell is faster at that. For the copy that has to live somewhere else, SimpleBackups for Neon runs pg_dump on a schedule, sends it to storage outside your Neon account, and alerts you when a run fails.

Keep learning

• Every pg_dump and pg_restore flag, with examples, for when you build the off-site copy yourself and need to know what -Fc changes about your restore options.
• Restore errors and what they mean, useful the first time a dump from Neon refuses to load into another Postgres host.
• Neon's project deletion and recovery docs, the page to read before anyone on your team has permission to delete a project.

FAQ

---

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