Neon Performance: Benchmarks, Latency & Limits 2026
Neon is serverless Postgres, compute split from storage, autoscaling 0.25 to 16 CU and scaling to zero. Independent tests hit 8,563 TPS at 29.8ms on 16 vCPU.
Neon Performance verdict
Neon is serverless Postgres with separated compute and storage.
Compute autoscales from 0.25 to 16 Compute Units, where 1 CU is 1 vCPU and 4 GB, and scales to zero after 5 minutes idle. Independent ClickHouse PostgresBench in April 2026 measured 8,563 TPS at a 29.8ms average and 49.2ms P99 latency at 16 vCPU on 100 GB, and 2,847 TPS at 4 vCPU.
Use Neon where autoscaling and scale-to-zero matter more than peak raw throughput, since dev, test and bursty workloads benefit most. Size compute at 8 to 16 CU for OLTP above 5,000 TPS. Disable scale-to-zero on paid plans for latency-sensitive production, where cold starts are unacceptable. Enable PgBouncer pooling for high connection counts, and prefer direct TCP over the serverless HTTP driver for sub-50ms paths.
- The benchmark numbers are fixed-compute runs, so under autoscaling the same workload behaves differently as the CU count adjusts to load.
- Scale-to-zero adds a cold start of a few hundred milliseconds after idle, longer past 7 days, though paid plans can disable it for latency-sensitive workloads. Autoscaling is bounded by a max delta of 8 CU, and computes over 16 CU are fixed-size and always active.
- pg_stat_statements resets its statistics on every scale-to-zero suspension, which limits cross-session query performance tracking.
- Peak throughput (independent)
- 8,563 TPS @ 16 vCPU
- Avg / P99 latency (independent)
- 29.8 / 49.2 ms
- Autoscaling range
- 0.25 to 16 CU
- Cold start
- few hundred ms
- Pooled connections
- 10,000 / endpoint
This page covers Neon's latency, throughput and scaling. Backups and pricing live on their own pages.
Browse the full Neon plan catalog
| Plan | Compute | Branches | PITR window | Price |
|---|---|---|---|---|
| Free | 0.25 to 2 CU autoscale | 10 | 6 hours | $0 |
| LaunchPopular | Up to 16 CU autoscale | 10 | Up to 7 days | $0.106 / CU-hr |
| Scale | Up to 56 CU (fixed) | 25 | Up to 30 days | $0.222 / CU-hr |
Compute is billed per CU-hour (1 CU = 1 vCPU + 4 GB), storage at $0.35/GB-month, extra branches at $1.50/branch-month. Scale-to-zero after 5 minutes idle (Free cannot disable). Free plan caps storage at 0.5 GB/project.
Intro prices are first-term promotional rates. Usage-based: compute is billed per CU-hour (1 CU = 1 vCPU + 4 GB), storage at $0.35/GB-month. Full catalog from Neon; verify live pricing before buying.
Neon query latency profile
| Measurement | Config | Result | Source |
|---|---|---|---|
| Avg latency | 16 vCPU / 64 GB, ~100 GB | 29.8 ms | ClickHouse PostgresBench |
| P99 latency | 16 vCPU / 64 GB, ~100 GB | 49.2 ms | ClickHouse PostgresBench |
| Avg latency | 4 vCPU / 16 GB, ~100 GB | 89.9 ms (P99 116.5) | ClickHouse PostgresBench |
| Avg latency | 16 vCPU / 64 GB, ~500 GB | 32.8 ms (P99 56.3) | ClickHouse PostgresBench |
| Cold start (scale-to-zero) | Project idle < 7 days | few hundred ms | Neon docs |
| Cached page latency | Compute RAM / local NVMe | memory / microsecond | Neon docs |
Throughput and connection limits
| Dimension | Value | Notes |
|---|---|---|
| Peak throughput | 8,563 TPS | 16 vCPU / 64 GB at ~100 GB; pgbench -c256 -j16 |
| Throughput (4 vCPU) | 2,847 TPS | 4 vCPU / 16 GB at ~100 GB |
| Throughput (500 GB) | 7,802 TPS | 16 vCPU / 64 GB at ~500 GB dataset |
| Pooled connections | 10,000 / endpoint | PgBouncer transaction mode; hard limit |
| Pool mode | Transaction (PgBouncer) | Connections returned to pool after each transaction; no session mode |
| Direct connections (16 CU) | 4,000 (capped) | max_connections scales with CU; capped at 4,000 |
Scale ceilings and the autoscaling model
| Aspect | Value | Notes |
|---|---|---|
| Autoscaling range | 0.25 to 16 CU | Live CU adjustment without restarts |
| Max fixed compute (Scale) | 56 CU / 224 GB | Fixed size only; always active over 16 CU |
| Autoscaling max delta | 8 CU (max minus min) | e.g. min 2 CU caps at max 10 CU |
| Scale-to-zero | 5 min idle | Default all plans; Free cannot disable, paid plans can |
| CU definition | 1 CU = 1 vCPU + 4 GB | Autoscaling adjusts CU count to live load |
| Storage (Free cap) | 0.5 GB / project | Storage billed $0.35/GB-month above plan allowance |
Neon reliability and architecture
- Neon separates the compute layer (optimized for latency) from the storage layer (optimized for correctness, history and scale), so compute is stateless and can restart or autoscale without data loss
- Durability rests on a Paxos-based Safekeeper WAL quorum: a transaction is committed once a quorum of Safekeepers has acknowledged the WAL record, protecting against the loss of any single Safekeeper node
- The Pageserver reconstructs database pages from WAL and serves cold pages, while object storage holds long-term immutable history and is never on the hot query path
- Autoscaling dynamically adjusts the amount of compute allocated in response to live load without restarts or manual intervention, within the configured min-max range
- Neon runs standard Postgres 14 through 17, set at project creation; pg_stat_statements is available but its statistics reset on each compute suspension (scale-to-zero), limiting cross-session tracking
- Connection scaling uses PgBouncer in transaction mode, pooling up to 10,000 client connections per endpoint, so connection-heavy apps scale beyond the per-CU direct limit
Neon benchmark results, independently measured
- The ClickHouse PostgresBench (April 2026) is an open-source, reproducible pgbench benchmark published by a peer competitor, run with 256 clients, 16 threads and 600-second runs in prepared mode
- At 16 vCPU / 64 GB on a ~100 GB dataset Neon reached 8,563 TPS with a 29.8ms average and 49.2ms P99 latency, its strongest measured configuration
- At 4 vCPU / 16 GB Neon reached 2,847 TPS with an 89.9ms average and 116.5ms P99, so throughput and latency scale strongly with compute size
- On a larger ~500 GB dataset the 16 vCPU configuration held 7,802 TPS at a 32.8ms average and 56.3ms P99, showing graceful degradation as data size grows
- These independent numbers reflect fixed-compute runs; under autoscaling the same workload behaves differently as the CU count adjusts to load, and the separated-storage architecture keeps object storage off the commit path
Neon Performance FAQ
How fast is Neon in independent benchmarks?
The independent ClickHouse PostgresBench, run in April 2026 with open-source pgbench, measured Neon at 8,563 TPS on a 100 GB dataset. That was a 29.8ms average and 49.2ms P99 latency at 16 vCPU and 64 GB, dropping to 2,847 TPS with an 89.9ms average at 4 vCPU. On a larger 500 GB dataset the 16 vCPU config held 7,802 TPS at 32.8ms. These are fixed-compute runs, so under autoscaling the same workload behaves differently as CU adjusts.
What is a Neon Compute Unit (CU)?
One CU allocates 1 vCPU and 4 GB of RAM. Autoscaling adjusts the CU count between a configured minimum and maximum in response to live load, without restarts, with the max delta capped at 8 CU. Computes larger than 16 CU are fixed-size and always active, not eligible for scale-to-zero. Neon plans range from 0.25 to 2 CU on Free, up to 16 CU autoscale on Launch, and up to 56 CU fixed on Scale.
How long is Neon's cold start after scale-to-zero?
Computes scale to zero after 5 minutes of inactivity by default, and activation generally takes a few hundred milliseconds for projects idle under 7 days, slightly longer past that. Postgres memory buffers are cold after wake-up, so the first queries run slower until caches warm. Paid plans can disable scale-to-zero to keep compute always active, while the Free plan cannot.
How many connections does Neon support?
Direct connection limits scale with CU size, for example about 1,676 at 4 CU, capped at 4,000 at 16 CU. For higher concurrency, Neon runs PgBouncer in transaction mode, which pools up to 10,000 client connections per endpoint. Transaction mode returns connections to the pool after each transaction, so SET and RESET, LISTEN and NOTIFY, and session-level prepared statements are unsupported on the pooled endpoint.
How does Neon's architecture affect performance?
Neon separates compute from storage. Pages cached in the compute node's RAM or local NVMe are served at memory speed. Uncached pages are reconstructed from WAL by the Pageserver, and object storage for long-term history is never on the hot path. A Paxos-based Safekeeper WAL quorum sets commit latency, while the Pageserver stays off the commit critical path. This is what enables instant branching and scale-to-zero.
Should I use scale-to-zero in production?
It depends on latency tolerance. Scale-to-zero saves cost on idle databases but adds a few-hundred-millisecond cold start on the first request after idle. For latency-sensitive production workloads where cold starts are unacceptable, disable scale-to-zero on a paid plan to keep compute always active. For dev, test, preview branches and bursty workloads, scale-to-zero is a strong cost lever.
Sources & verification
| Source | What was checked | Last checked |
|---|---|---|
| Neon Official | Official product page | July 10, 2026 |
| ClickHouse Blog Postgresbench | Independent reference | July 10, 2026 |
| Neon Connect Connection Pooling | Connect Connection Pooling | July 10, 2026 |
| Neon Introduction Architecture Overview | Introduction Architecture Overview | July 10, 2026 |
| Neon Introduction Autoscaling | Introduction Autoscaling | July 10, 2026 |
| Neon Introduction Compute Lifecycle | Introduction Compute Lifecycle | 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 performance.