Neon Backups, Scaling & Operations 2026
Neon's operations run on copy-on-write branching: PITR is a branch restore within the history window, dev branches clone instantly. Read replicas are same-region.
Neon Backups & Operations verdict
Neon's operations center on copy-on-write branching.
PITR is a branch restore to a point within the history window, 6 hours on Free, up to 7 days on Launch, up to 30 days on Scale. Dev and test branches clone instantly with zero parent impact.
Lean on Neon branching for dev and test, preview environments and instant PITR: create a branch per pull request and roll back by restoring to a timestamp. For read scaling, add same-region read replicas. For cross-region resilience, plan a logical-replication target in another region. Set the PITR window to your recovery objective, and budget the storage it adds. Decide on autoscaling and logical replication up front, since neither can be reverted once set.
- Enabling autoscaling and logical replication cannot be reverted once set on a project.
- Read replicas are same-region and eventually consistent, so cross-region resilience needs logical replication to a separate project. PITR is bounded by the history window, fixed at 6 hours on Free, and extending it raises storage cost.
- Neon publishes no specific compute-failover RTO SLA, since recovery is a stateless restart from durable storage.
- PITR window
- 6h / 7d / 30d by plan
- Backup model
- Copy-on-write history
- HA durability
- Safekeeper Paxos quorum
- Read replicas
- Same-region, share storage
- Branching
- Instant, zero parent impact
This page covers Neon's backups, HA and day-2 ops. Latency and pricing live on their own pages.
High availability and replication
| Mechanism | Behavior | Scope | Notes |
|---|---|---|---|
| WAL durability | Safekeeper Paxos quorum | Storage durability layer | Commit acknowledged once a quorum of Safekeepers has the WAL record |
| Compute failover | Automatic (stateless restart) | Compute layer | Compute is stateless and reads from durable storage; no published RTO SLA |
| Read replicas | Same-region, async | Read scalability | Share the same storage as primary; eventually consistent; scale to zero when idle |
| Read replicas (Free cap) | 3 per project | Free plan limit | Launch and Scale allow more; same-region only |
| Cross-region replication | Logical replication | Separate Neon project | No native cross-region read replicas; replicate to a project in another region |
Check Neon recovery and availability fit
- Recovery time: documented failover is Automatic compute failover (stateless restart from durable storage); no published RTO SLA, stated RTO Seconds (stateless compute restart); no published SLA.
- Point-in-time recovery: point-in-time recovery up to 30 days back.
- Availability: single-region high availability across AZs is available.
- Backups: Continuous (copy-on-write WAL history), retained 30 days; RPO Near-zero (Safekeeper WAL quorum commit).
Based on Neon's documented operations capabilities. Confirm SLAs against the vendor contract.
Neon operational configuration
Point-in-time recovery is a branch restore to a timestamp within the project history window. Restore main to a past time, preserving the current state as a backup branch, or create a fresh instant-restore branch at a past timestamp.
# Restore main to a point in time, keeping the current state as a backup branch
neonctl branches restore main ^self@2026-06-27T10:00:00.000Z \
--preserve-under-name main_pre_restore
# Or create a new instant-restore branch at a past timestamp (within the history window)
neonctl branches create --name recovery --parent 2026-06-27T10:00:00.000ZAdd a read replica by creating a read-only compute (it scales to zero when idle and shares the primary's storage). Set the autoscaling CU range when you create a branch, using a min-max delimited by a dash (max delta 8 CU).
# Add a read replica (read-only compute, same-region, scales to zero when idle)
neonctl branches create --name analytics_replica --type read_only
# Create a branch with an autoscaling CU range (min-max, max delta 8 CU)
neonctl branches create --name api --cu 0.5-8
# Or a fixed-size compute
neonctl branches create --name worker --cu 2Neon backups and point-in-time recovery
| Plan / aspect | PITR window | Default history | Notes |
|---|---|---|---|
| Free | 6 hours | 6 hours (fixed) | Cannot be extended; 0.5 GB/project storage cap |
| Launch | Up to 7 days | 1 day (default) | Configurable up to 7 days |
| Scale | Up to 30 days | 1 day (default) | Configurable up to 30 days |
| Restore mechanism | Copy-on-write branch | Instant restore | Roll a branch back to any point within the history window |
| History storage cost | Proportional to window | More WAL deltas | Storage billed at $0.35/GB-month; longer history = more storage |
| Free storage cap | 0.5 GB / project | Limits history | Caps practical history on the Free plan |
Scaling operations and branching
| Operation | Behavior | Notes |
|---|---|---|
| Compute autoscaling | Live, no restart | Adjusts CU within min-max; max delta 8 CU; 0.25 to 16 CU |
| Scale-to-zero | 5 min idle | Free cannot disable; paid plans can keep always-active |
| Branching | Copy-on-write, instant | A 50 GB database branches in the same time as a 1 GB one, under a second |
| Branches per plan | 10 / 10 / 25 | Free 10, Launch 10, Scale 25; extra at $1.50/branch-month |
| Branch compute | Dedicated, autoscaling | Each branch has its own autoscaling, scale-to-zero compute |
| Parent impact | Zero load | Branch creation and writes do not affect the parent branch |
What to verify before you commit to Neon
- Enabling autoscaling and logical replication cannot be reverted once set on a project, so decide on them deliberately rather than toggling them later
- Read replicas are same-region only and eventually consistent; cross-region resilience requires logical replication to a separate Neon project in another region, which adds lag and operational overhead
- PITR is bounded by the retained history window (fixed 6 hours on Free, up to 7 days on Launch, up to 30 days on Scale), and extending it increases storage cost, so size the window to your recovery objective
- Branches share copy-on-write storage with their parent, so they are cheap to create but diverging writes accrue storage as deltas; budget the $1.50/branch-month for extra branches and prune stale ones
Neon Backups & Operations FAQ
How does Neon handle backups and point-in-time recovery?
Neon's backup model is its copy-on-write history rather than nightly dumps. PITR works by restoring a branch to any point within the retained history window: 6 hours on Free, fixed, up to 7 days on Launch and up to 30 days on Scale. Restores are instant, because they branch from existing history. Extending the window keeps more WAL deltas and raises storage cost, at $0.35 per GB-month.
What is Neon's high-availability model?
Durability rests on a Paxos-based Safekeeper WAL quorum. A transaction commits once a quorum of Safekeepers has acknowledged the WAL record, so losing a single Safekeeper does not lose data. Compute is stateless and reads from durable storage, so it fails over by restarting automatically. Neon publishes no specific compute-failover RTO SLA, so validate recovery timing for your workload.
Does Neon support read replicas and cross-region replication?
Yes for read replicas: independent read-only computes that share the same storage as the primary, with no data duplication, asynchronous and eventually consistent, scaling to zero when idle. The Free plan caps them at 3 per project. Read replicas are same-region only. For cross-region you use logical replication to a separate Neon project in another region, which adds replication lag.
How does Neon's database branching work?
Branches are copy-on-write clones created instantly regardless of database size. A 50 GB database branches in the same time as a 1 GB one, under a second, with zero impact on the parent. Writes to a branch are stored as deltas, so branches are cheap. Each branch gets its own autoscaling, scale-to-zero compute, so dev, test and preview environments run in parallel. Plans include 10 branches on Free and Launch to 25 on Scale, with extras at $1.50 per branch-month.
How do I operate Neon from the command line?
Use the neonctl CLI. For PITR, neonctl branches restore main ^self@<timestamp> --preserve-under-name <backup> restores main to a point in time while keeping the old state. To add a read replica, neonctl branches create --name <name> --type read_only. To set an autoscaling range, neonctl branches create --name <name> --cu 0.5-8, a dash-delimited min-max with a max delta of 8 CU. You can also branch at a past timestamp with --parent for an instant-restore branch.
What operational limits should I plan around?
Autoscaling and logical replication cannot be reverted once enabled on a project, so decide up front. Read replicas are same-region only. The PITR window is fixed at 6 hours on Free and configurable up to 7 days on Launch or 30 days on Scale. Computes over 16 CU are always active, with no scale-to-zero, and the Free plan caps storage at 0.5 GB per project and read replicas at 3 per project.
Sources & verification
| Source | What was checked | Last checked |
|---|---|---|
| Neon Official | Official product page | July 10, 2026 |
| Neon Introduction Architecture Overview | Introduction Architecture Overview | July 10, 2026 |
| Neon Introduction Autoscaling | Introduction Autoscaling | July 10, 2026 |
| Neon Introduction Branching | Introduction Branching | July 10, 2026 |
| Neon Introduction Point In Time Restore | Introduction Point In Time Restore | July 10, 2026 |
| Neon Introduction Read Replicas | Introduction Read Replicas | July 10, 2026 |
| Neon Pricing | Pricing and plans | July 10, 2026 |
Every fact on this Neon page is tied to a named source and a verification date. Freshness-sensitive figures trace to the sources above; verify against the vendor before relying on them.
Explore Neon
Every page on Neon in one place, you are on operations.