Serverless Postgres at Scale: Hidden Trade-offs in Compute–Storage Separation?

[jeet-dev111]

For teams running Neon in production at scale, I’m curious about the less obvious trade-offs of the compute–storage separation model.

At what workload patterns (high connection churn, low-latency OLTP, heavy analytical bursts) do you start to see measurable performance overhead compared to traditional stateful Postgres clusters?

How significant are cold-start penalties in latency-sensitive systems?

Are there benchmarks comparing Neon’s architecture to managed Postgres with read replicas under similar load?

Trying to understand where the architectural boundaries realistically are.

[rajputomsingh]

For teams running Neon in production at scale, the compute–storage separation model provides flexibility but introduces subtle trade-offs.

→ High connection churn: Workloads like multi-tenant SaaS or ephemeral queries add overhead because each compute node must attach to the shared storage layer and rebuild page caches.
→ Low-latency OLTP impact: Even small network round-trips between compute and storage can accumulate, affecting response times.
→ Analytical workloads: Large sequential scans may be slower since data is fetched over the network rather than from local disk, limiting throughput.
→ Cold-start penalties: When a compute node spins up or attaches to a timeline, cache warming and WAL replay can temporarily delay queries.
→ Benchmark comparisons: Traditional managed Postgres with dedicated read replicas may outperform Neon in sustained high-throughput or ultra-low-latency workloads.
→ Best-use scenarios: Neon excels in bursty, dynamic, or branching workloads, and in multi-tenant environments, but consistent, latency-critical workloads require careful planning to mitigate overhead.