# Serverless Postgres: where scale-to-zero actually reaches zero

> Scale-to-zero rarely reaches zero. How to compute the serverless-versus-provisioned Postgres crossover from your workload's duty cycle.

- Source: https://ivankarpinskyi.dev/blog/serverless-postgres-vs-instance
- Published: 2026-08-28
- Type: Decision
- Tags: postgres, serverless, neon, aurora, cost
- Reading time: 11 min

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](https://github.com/neondatabase/neon/discussions/12900) 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](https://www.vantage.sh/blog/neon-vs-aws-aurora-serverless-postgres-cost-scale-to-zero) 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.

**Neon's monthly compute bill as a share of Aurora Serverless v2's**

| | Value, % |
| - | -: |
| Test env, idle 4/5 of the time | 80 |
| Batch job, idle 2/3 of the time | 89 |
| **Social analytics, rarely idle** | 133 |

_My arithmetic over Vantage's three modelled scenarios, March 2024 list prices, US-East, compute only. Under 100 means Neon is cheaper._

The dollar figures behind those bars are dead. Neon [moved to usage-based pricing](https://neon.com/blog/new-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](https://neon.com/docs/introduction/architecture-overview) 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](https://jack-vanlightly.com/analyses/2023/11/15/neon-serverless-postgresql-asds-chapter-3) 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`](https://neon.com/blog/get-page-at-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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html) 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](https://thebuild.com/blog/2026/04/28/managed-postgres-examined-amazon-rds-for-postgresql) 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.

| | Where durable state lives | What scales on its own | Cost of an idle hour |
| - | - | - | - |
| Neon | Pageservers plus S3, multi-tenant | Compute, down to nothing | Control-plane floor, not zero |
| Aurora Serverless v2 | Shared cluster volume, 6 copies / 3 AZs | Compute, in 0.5-ACU steps | Zero, unless a blocker applies |
| RDS provisioned | EBS volume on the instance | Nothing until you resize | Full instance rate |

## Scale-to-zero switches off exactly where production lives

Aurora Serverless v2 only got a true zero floor on [20 November 2024](https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-aurora-serverless-v2-scaling-zero-capacity). Before that the minimum was 0.5 ACU, charged forever.

- **Aurora Serverless v2 minimum idle cost**: 43.80 → 0 $/mo. The 0.5 ACU floor applied until 20 November 2024; zero applies afterwards, if nothing on the blocker list is switched on.
- **Neon Launch compute rate**: 0.14 → 0.106 $/CU-h. 14 August 2025 to 7 November 2025, six months after the Databricks acquisition.

The blocker list is the interesting half. Per [AWS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html), 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.

> **The point**
>
> Every item on that list is something a production database has and a demo database does not. Scale-to-zero is a feature of your staging environment, and the cost model that assumes it works applies to staging too.

Neon runs into the same contradiction from the other side. Its own documentation on [`pg_cron`](https://neon.com/docs/extensions/pg-extensions) 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](https://neon.com/docs/guides/logical-replication-concepts) 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](https://github.com/neondatabase/neon/discussions/12909) 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.

**Time to first response after suspend**

| | Value, ms | Note |
| - | -: | - |
| Neon, vendor claim | 500 | method not published |
| Neon, independent test | 800 | includes Lambda start |
| **Aurora Serverless v2 resume** | 15000 | |
| Aurora after 24h+ paused | 30000 | deep sleep |

_Neon's 500 ms is the vendor's own figure with no published method; the 800 ms row is an independent practitioner test whose author notes it includes Lambda's own cold start; Aurora's figures come from AWS documentation. Lower is better._

Neon's own number improved tenfold in [July 2023](https://neon.com/blog/cold-starts-just-got-hot), 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](https://github.com/neondatabase/serverless/issues/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](https://neon.com/docs/connect/connection-pooling) 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](https://andrewbaker.ninja/2026/02/21/aurora-serverless-v2-postgresql-production-scaling-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](https://neon.com/blog/postmortem-delayed-start-compute-operations). 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.

> **Warning · The provisioned instance is not safer — it fails less publicly**
>
> Neon's incidents are unusually visible because one multi-tenant vendor publishes postmortems for everyone at once. Failures of self-managed and provisioned deployments — [both replicas in the same zone](https://sxnlabs.com), disks filled by logs — scatter across thousands of separately operated instances with no central registry. That asymmetry is selection bias in the evidence, not evidence of reliability.

## 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.

- **8 ACU held busy for one hour**: 0.96 $. Aurora Standard at $0.12/ACU-h — roughly the memory of a db.r6g.large. My arithmetic over AWS list prices.
- **db.r6g.large on-demand, same hour**: 0.225 $. 2 vCPU, 16 GiB, AWS list price. Against a three-year reserved instance the multiple is far worse.

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](https://dev.to/kinde/what-is-aws-aurora-serverless-v2-and-why-we-didnt-use-it-102b): 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](https://www.vantage.sh/blog/neon-acquisition-new-pricing) to Databricks' wholesale AWS position rather than to any engineering change, having [bought Neon for about $1 billion](https://techcrunch.com/2025/05/14/databricks-to-buy-open-source-database-startup-neon-for-1b/) 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](https://arxiv.org/abs/2604.17180), 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.

- **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.
- **Steady OLTP, busy most of the working day** → Provisioned instance (reserved 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.
- **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.
- **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.
- **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](https://github.com/neondatabase/neon/discussions/12909) and revisiting the won't-fix on [#12900](https://github.com/neondatabase/neon/discussions/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](https://planetscale.com/benchmarks/neon-lakebase), 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.

> **Note**
>
> Prices and limits here are current as of August 2026. This subject ages badly: Aurora Serverless v2 could not scale to zero until November 2024, Neon storage cost $1.75/GB-month before dropping to $0.35, and Aurora Serverless v1 reached end of life on 31 March 2025. Any comparison you find that mentions v1 as a live product, or a 0.5 ACU floor, predates the thing it is describing.

## Sources

- [closed the report](https://github.com/neondatabase/neon/discussions/12900), github.com
- [modelled three synthetic workloads](https://www.vantage.sh/blog/neon-vs-aws-aurora-serverless-postgres-cost-scale-to-zero), vantage.sh
- [moved to usage-based pricing](https://neon.com/blog/new-usage-based-pricing), neon.com
- [Pageservers](https://neon.com/docs/introduction/architecture-overview), neon.com
- [independent architectural analysis](https://jack-vanlightly.com/analyses/2023/11/15/neon-serverless-postgresql-asds-chapter-3), jack-vanlightly.com
- [GetPage@LSN](https://neon.com/blog/get-page-at-lsn), neon.com
- [cluster volume](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html), docs.aws.amazon.com
- [unmodified community Postgres on one EC2 instance](https://thebuild.com/blog/2026/04/28/managed-postgres-examined-amazon-rds-for-postgresql), thebuild.com
- [20 November 2024](https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-aurora-serverless-v2-scaling-zero-capacity), aws.amazon.com
- [AWS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html), docs.aws.amazon.com
- [pg_cron](https://neon.com/docs/extensions/pg-extensions), neon.com
- [Logical replication](https://neon.com/docs/guides/logical-replication-concepts), neon.com
- [acknowledged on 10 July 2026](https://github.com/neondatabase/neon/discussions/12909), github.com
- [July 2023](https://neon.com/blog/cold-starts-just-got-hot), neon.com
- [issue #146](https://github.com/neondatabase/serverless/issues/146), github.com
- [built-in PgBouncer](https://neon.com/docs/connect/connection-pooling), neon.com
- [independent production guide](https://andrewbaker.ninja/2026/02/21/aurora-serverless-v2-postgresql-production-scaling-guide/), andrewbaker.ninja
- [creating and waking suspended computes broke while active databases kept serving](https://neon.com/blog/postmortem-delayed-start-compute-operations), neon.com
- [both replicas in the same zone](https://sxnlabs.com), sxnlabs.com
- [the same shape from production](https://dev.to/kinde/what-is-aws-aurora-serverless-v2-and-why-we-didnt-use-it-102b), dev.to
- [attributes the cut](https://www.vantage.sh/blog/neon-acquisition-new-pricing), vantage.sh
- [bought Neon for about $1 billion](https://techcrunch.com/2025/05/14/databricks-to-buy-open-source-database-startup-neon-for-1b/), techcrunch.com
- [BranchBench](https://arxiv.org/abs/2604.17180), arxiv.org
- [published by PlanetScale](https://planetscale.com/benchmarks/neon-lakebase), planetscale.com