Serverless Postgres: Where Scale-to-Zero Actually Reaches Zero

Four Neon projects on the Launch plan, 0.25 CU each, auto-suspend set to five minutes, burned a flat six compute-hours a day between them. Thirty visitors a day or six hundred — the same bill either way. The traffic was not keeping the compute awake; Neon's own check_availability pings from the control plane were, and staff closed the report by describing that floor as a minimum operational cost of running the service. Won't fix, by design.

That floor is the number the whole serverless-versus-provisioned comparison turns on, and nearly every cost model sets it to zero.

The choice itself is arithmetic you can run before you migrate. It takes two inputs: what fraction of the hour your database genuinely does work, and what your idle actually bills — not what the pricing page implies it bills.

The sign of the saving flips across three ordinary workloads

Vantage modelled three synthetic workloads against published list prices in March 2024: a test environment idle four fifths of the time, a social-analytics database that rarely goes quiet, and a batch job idle two thirds of the time. Compute only, no storage or I/O, US-East.

The dollar figures behind those bars are dead. Neon moved to usage-based pricing in August 2025, cut compute rates that November and dropped the monthly minimum in December, so nobody should quote $70.08 a month at anyone in 2026. The shape survives the repricing, because it comes from the billing model rather than the rate: one vendor charges for allocated capacity, the other for consumed capacity, and the two curves cross wherever consumption stops being intermittent.

None of the three profiles is exotic. That is the uncomfortable part — the same pair of products, priced from the same page, produces a 20% saving and a 33% penalty depending on nothing more than how often the database is busy.

Why the compute can disappear at all

Neon splits Postgres into three services. Pageservers materialise pages from base images plus WAL; Safekeepers form a redundant WAL service where a write becomes durable on quorum; the compute node is a stock Postgres binary that streams its WAL outward instead of writing to a local disk. An independent architectural analysis adds the detail the docs skip: Safekeepers run three-node Multi-Paxos, not Raft, with Postgres as proposer and Pageservers as learners.

Page materialisation happens off the transaction's critical path. A compute asks for a page at a specific LSN, the Pageserver finds the nearest image layer and replays deltas forward to reach it — GetPage@LSN, served asynchronously, with layer files of 128–256 MB pulled from S3 on a cache miss.

Suspension is cheap because of that split, not because of clever engineering around shutdown. Durable state already lives outside the compute tier, so nothing has to be flushed or copied before the VM goes away. Waking up rebuilds only the ephemeral part: a fresh Postgres process and cold caches.

Which means the aggressive suspend timeout is a pricing decision. The same analysis says so plainly — Neon could keep computes warm far longer; it chooses not to, because idle capacity is what the model is designed to avoid paying for.

Aurora separates storage and compute too, but along a different seam. The cluster volume is a replicated SSD substrate holding six copies across three availability zones, shared by every instance in the cluster, and it exists in provisioned Aurora as well. Serverless v2 only makes the compute half elastic, in 0.5-ACU steps measured every second, where an ACU is roughly 2 GiB of memory plus proportional CPU and network.

A classic RDS instance does none of this. It runs unmodified community Postgres on one EC2 instance attached to an EBS volume, provisioned and billed together, around the clock, with capacity fixed until somebody resizes it by hand. Its Multi-AZ story is block-level synchronous replication of EBS rather than Postgres streaming replication — the standby is not queryable, and failover is a DNS re-point taking 60 to 120 seconds.

Separation is a design choice rather than the direction of travel, incidentally. PlanetScale shipped Postgres in September 2025 on Kubernetes with directly attached NVMe, deliberately declining the disaggregated model while copying the branching UX that sells it.

Scale-to-zero switches off exactly where production lives

Aurora Serverless v2 only got a true zero floor on 20 November 2024. Before that the minimum was 0.5 ACU, charged forever.

The blocker list is the interesting half. Per AWS documentation, auto-pause does not engage while logical replication is configured, while RDS Proxy sits in front, while the cluster is part of a Global Database, or while a single client connection stays open. It also needs Aurora PostgreSQL 13.15, 14.12, 15.7 or 16.3 as a minimum.

Neon runs into the same contradiction from the other side. Its own documentation on pg_cron notes the extension only fires while compute is active, and recommends disabling autosuspend for projects that depend on scheduled jobs — which is to say, disabling the product's headline feature. Logical replication needs an unpooled direct connection and drops replication slots after 75 minutes of inactivity. Custom C extensions are not permitted at all; you get what is on the allow-list.

Then there is the failure mode that has nothing to do with your code. A user documented that Neon Auth introspects information_schema.tables roughly twice a second, around the clock, on any project using it — 1,383 introspection cycles across 105.2 hours, billing 0.49 CU-hours per idle hour, about four times the expected figure. A second user reproduced it independently. Neon staff acknowledged on 10 July 2026 that a debounce check meant to run once every 60 seconds shipped missing from the beta. As of 21 August 2026 it is still open.

Waking up is where the latency and the incidents live

The gap between the two serverless offerings on resume is not marginal.

Neon's own number improved tenfold in July 2023, from 3–6 seconds down to the half-second range, and an independent practitioner test on readysetcloud.io, run against a free-tier database idle for five minutes, measured roughly 800 ms round-trip with Lambda's own start time folded in. Those figures are close enough that the honest reading is "sub-second, method unclear." AWS, by contrast, documents 15 seconds as typical and tells you to set client timeouts above it.

What the vendor numbers do not cover is the unstable case. The same independent report describes intermittent SSL connection has been closed unexpectedly errors on reconnect, and issue #146 against Neon's serverless driver — periodic SocketError: other side closed taking down Next.js server functions — was closed as not planned with no documented root cause.

Connection ceilings behave counterintuitively on both. Neon's built-in PgBouncer accepts up to 10,000 client connections and multiplexes them onto 90% of max_connections, but at compute sizes of 9 CU and above max_connections is hard-capped at 4,000 regardless of how much RAM you bought. On Aurora Serverless v2, max_connections derives from the maximum configured ACU rather than current capacity, and is separately capped at 2,000 when the minimum is set to 0 or 0.5. An independent production guide names the common failure precisely: not a capacity problem, but a connection storm inside the lag window before ACUs catch up with demand.

Neon also has two documented outages that hit exactly this path. On 16 and 19 May 2025, 5.5 hours combined in us-east-1, creating and waking suspended computes broke while active databases kept serving. Root cause: a query plan regression inside Neon's own control-plane database slowed control queries by 10–100×, suspension of idle computes stalled, active pods ballooned to around 8,000 against a planned 6,000, and two of three subnets ran out of IP addresses.

At full load you are renting a CPU at four times the price

Neon prices a CU as 1 vCPU plus 4 GB of RAM: $0.106 per CU-hour on Launch, $0.222 on Scale. Aurora charges $0.12 per ACU-hour on Standard, $0.156 on I/O-Optimized, and does not publish the vCPU side of the ACU ratio at all. Normalise by memory instead, and the picture is unambiguous.

That is 4.3× for capacity held at full tilt, and it is a floor rather than a worst case — a three-year reservation pushes the ratio past 12×. Kinde reported the same shape from production: 80 ACU costing more than twice an equivalent db.r8g.8xlarge on-demand, with worse latency and roughly 15 minutes to scale up to 90 ACU. Their post carries no date, so treat it as a direction rather than a current measurement.

That premium buys an option: the right to stop paying when the work stops. Options cost money whether or not you exercise them, and a database at 100% duty cycle never exercises this one.

The rates themselves have also stopped standing still. Neon changed pricing three times in eight months — usage-based in August 2025, roughly 15% off compute that November, the $5 monthly minimum removed in December — and Vantage attributes the cut to Databricks' wholesale AWS position rather than to any engineering change, having bought Neon for about $1 billion in May 2025. Run the arithmetic with a shelf life in mind.

One more caution for anyone choosing serverless for branching rather than cost. BranchBench, an academic benchmark from Columbia published in April 2026, tested five branching systems on agentic workloads and found reads 5× to 4,000× slower as branch depth grows, plus a hard limit of 20 concurrent live branches on Neon's highest paid tier — in a 1,000-step Monte Carlo Tree Search experiment, Neon completed 3% of the steps. DoltHub, a competitor tested in the same paper, confirmed the extreme read figure on its own blog in June 2026 while disputing parts of the methodology. Databricks justified the acquisition by saying over 80% of Neon databases are created by agents; the branching those agents need does not currently scale.

How I would choose

By duty cycle first, then by which items on the blocker list you cannot give up.

1. Preview databases per pull request, idle most of the week

   Serverless, either vendor

   This is the profile the model was built for, and the one where Vantage measured a real 20% saving. Branch depth stays shallow and nothing needs replication.

2. Steady OLTP, busy most of the working day

   Provisioned instancereserved capacity widens the gap further

   You are paying 4× or more for elasticity you never use. The savings plan you can buy on a provisioned instance has no serverless equivalent.

3. Logical replication to a warehouse, RDS Proxy, or pg_cron in the schema

   Provisioned, or serverless with autosuspend off

   Each of these blocks auto-pause on Aurora or defeats it on Neon. Choosing serverless here means paying serverless rates for an always-on database.

4. Spiky traffic with a latency SLO on the first request after a lull

   Aurora with minimum ACU above realistic idle

   Fifteen seconds to resume is a documented AWS figure, not a tail. If sub-second wake matters more than the floor, Neon is the only one of the two that offers it.

5. Internal tool serving a few hundred requests a day

   Neon, budgeting a few dollars of floor

   Cheapest option on the table by a wide margin — as long as you write the control-plane floor into the forecast rather than assuming zero.

What would change the answer

Three things I am watching, each of which would move a branch above.

Neon closing #12909 and revisiting the won't-fix on #12900 would make the idle side of the arithmetic match the pricing page. Until then, model idle at measured CU-hours, not at zero.

AWS removing open client connections and RDS Proxy from the auto-pause blocker list would move Aurora's zero floor from staging into production, which is where the 0-ACU announcement is already read as applying.

And the gap worth watching is the one that does not exist yet: there is no independent, vendor-neutral three-way benchmark of Neon, Aurora Serverless v2 and provisioned RDS. The only sysbench and TPCC comparison in circulation was published by PlanetScale, a direct competitor of one of the subjects. Every throughput claim in this space currently traces back to somebody with a stake in the result.