Short answer
Neon's instant restore returns a root branch to any timestamp inside the history window. There's no pg_restore, no waiting for a backup to download, no replaying WAL by hand. The window is 6 hours on the Free plan, up to 7 days on the Launch plan, and up to 30 days on the Scale plan. Child branches don't support instant restore.
How it works
A traditional restore copies data from a backup file. For a 200 GB database, that can take hours, and you typically restore to a new instance, then swap connection strings.
Lakebase Postgres storage already keeps the change history. Restoring to a timestamp is a metadata operation: the branch is reset to point at the right state, and writes resume from there. Two ways to do it:
Restore the root branch in place.
neon branches restore main ^self@2026-04-25T14:32:00Z \
--preserve-under-name main_old_pre_bugThe branch keeps its name and connection string. Any writes made after the target timestamp are discarded. Lakebase Postgres also keeps a backup branch under the name you pass to --preserve-under-name.
Branch from a timestamp.
neon branches create --name pre-incident \
--parent 2026-04-25T14:32:00ZThis gives you a separate branch at the pre-bug state. Useful when you want to inspect the historical data without touching production.
History window per plan
| Plan | History window | Cost |
|---|---|---|
| Free plan | 6 hours, capped at 1 GB of changes | Included |
| Launch plan | Up to 7 days | $0.20/GB-month |
| Scale plan | Up to 30 days | $0.20/GB-month |
You only pay for history on root branches; child branches don't add to the cost. See history window for how to configure it and reduce costs by shortening the window.
Restore in place is destructive
A restore in place drops writes that happened after the target timestamp. If you might need those rows for forensics or partial recovery, branch to a new name from the timestamp first, then merge what you need back.
What this replaces
Without instant restore, your options are: a daily pg_dump (you lose any data after the snapshot), continuous WAL archiving with manual point-in-time recovery (slow, error-prone), or a managed provider's PITR feature (usually requires a separate restore target). Neon collapses these into a single API call against the existing root branch.
How other Postgres providers restore
| Provider | Restore window | Restores to | Cost |
|---|---|---|---|
| Neon | 6 hours (Free plan), up to 30 days (Scale plan) | Same root branch or new branch | $0.20/GB-month on paid plans |
| Amazon RDS for Postgres | 0 to 35 days | New database instance | Backup storage above database size is billed separately |
| Aurora Postgres | Up to 35 days | New cluster | Backup storage above cluster size is billed separately |
| Supabase | 7 days (Pro daily), or PITR add-on up to 28 days | Same project (in place) | Daily included on Pro; PITR add-on from ~$100/mo |
-
RDS / Aurora. Continuous backups support PITR with retention of 0 to 35 days. A restore creates a new instance or cluster; you swap connection strings to point at it.
-
Supabase. Daily backups are available on Pro and above. Point-in-Time Recovery is a paid add-on with retention periods of 7, 14, or 28 days and a Small compute minimum. Restores happen in place; downtime depends on database size.
A Lakebase Postgres restore keeps the connection string stable on the same root branch. If you'd rather inspect history without touching the branch, create a new branch from the timestamp instead.

Set up a Neon project and restore to any point in seconds.








