Neon Pricing in 2026: What Serverless Postgres Costs

Neon (neon.com) sells Postgres by the compute-hour, and that one fact decides your whole bill. There is no instance to reserve and, when your database is idle, the meter is supposed to stop. The catch is that "idle" is a state you have to actually reach, and the most expensive mistake on Neon is paying for a database to sit awake while nobody is querying it. This teardown walks the 2026 rate card, the single setting that turns a $7 bill into a $40 bill at the same traffic, three worked 30-day bills, and the point where a plain fixed instance gets cheaper.

Quick answer: Neon pricing in 2026

Neon has three self-serve plans in 2026: Free at $0 a month with 100 CU-hours and 0.5 GB of storage included, Launch (usage-based, typical spend about $15 a month) that meters compute at $0.106 per CU-hour, and Scale (usage-based) that meters compute at $0.222 per CU-hour. Storage is $0.35 per GB-month on both paid plans, egress is free up to 500 GB then $0.10 per GB, and every plan scales to zero when the database goes idle (after 5 minutes by default). Your real invoice is almost entirely CU-hours, and the number that decides it is how many hours your compute stays awake, not how many queries you run.

Neon plans and rates, 2026

Neon runs real PostgreSQL, so the plan you pick changes the price of compute, not the engine. Here is the self-serve rate card as published on Neon's pricing page in 2026.

Two rates on that card do most of the damage. First, the Scale compute rate ($0.222) is 2.1x the Launch rate ($0.106), so moving up a tier roughly doubles the cost of every awake hour. Scale buys you a higher autoscale ceiling, configurable suspend, longer restore windows and an SLA; it is not a volume discount. Second, extra items meter separately and quietly: instant restore (retained write-ahead log) is $0.20 per GB-month, egress past 500 GB is $0.10 per GB, and each branch past your allowance is $1.50 per branch-month.

What a CU-hour actually is

A CU (compute unit) on Neon is 1 vCPU plus 4 GB of RAM. A CU-hour is one CU running for one hour. Because Neon autoscales, you are not billed for a fixed instance size; you are billed for the CU-seconds your database actually burns between its minimum and maximum size, summed up over the month.

That means the bill has only two levers: how big the compute scales, and how many hours it stays awake. It is not per query, not per connection, not per GB scanned. A database that answers ten thousand queries in a 20-minute burst and then sleeps costs a fraction of one that answers a hundred queries an hour, all day, because the second one never gets to stop the meter.

There are 730 hours in an average month. Hold that number; it is the difference between the cheap bill and the expensive one.

The one trap that 5x's your Neon bill

Scale-to-zero is the entire economic case for Neon, and it is the thing teams accidentally switch off. After 5 minutes of no queries, the compute suspends and billing for compute stops (you keep paying storage, which is cents). When a query arrives, it resumes in a few hundred milliseconds. If that suspend never fires, you pay for a CU to sit awake 730 hours a month whether or not anyone is using it.

Three things quietly keep a Neon database awake:

1. A long-lived connection from a traditional pooler or an always-on server holds the compute open, so the idle timer never reaches 5 minutes.
2. The minimum autoscale size is set above the smallest you need, so every awake hour costs more than it has to.
3. A health check or uptime monitor pings the database more often than the suspend window, resetting the idle timer on every hit and pinning the database awake around the clock.

The third one is the silent killer. A one-minute uptime ping is enough to turn a database that would have slept 26 days a month into one that never sleeps at all, at exactly zero added user traffic.

Three 30-day Neon bills, worked

Bill A, disciplined indie side project (Launch, scale-to-zero on). Sporadic traffic; the compute wakes for bursts roughly 4 hours a day at an average 0.5 CU. That is 0.5 x 4 x 30 = 60 CU-hours, or 60 x $0.106 = $6.36 of compute. Add 3 GB of storage at $0.35 = $1.05. Egress is under the 500 GB free tier. Total: about $7.41 a month.

Bill B, the exact same app with scale-to-zero disabled (Launch). Same traffic, same data, but a warm connection (or a health-check ping) keeps a 0.5 CU floor awake all month: 0.5 x 730 = 365 CU-hours, or 365 x $0.106 = $38.69, plus the same $1.05 of storage. Total: about $39.74 a month. Nothing about the workload changed. One setting added roughly $32 a month of pure idle compute and multiplied the bill 5.4x.

Bill C, growth-stage production, always-on (Scale). A real production database averaging 2 CU, running 24/7 because it genuinely serves traffic around the clock: 2 x 730 = 1,460 CU-hours at the Scale rate of $0.222 = $324.12. Add 50 GB of storage ($17.50) and about 30 GB of retained restore history at $0.20 ($6.00). Total: about $347.62 a month. The same always-on database billed at the Launch rate would be 1,460 x $0.106 = $154.76 of compute; the extra $170 is the Scale tier's higher per-hour rate, not extra usage.

Neon versus a fixed instance: the crossover

Neon is cheap when your database sleeps and expensive when it does not, which sets up a clean break-even against a plain fixed instance. Say a comparable always-on managed Postgres box (roughly 1 vCPU and 4 GB, about 1 CU) costs a flat $50 a month. Neon Launch charges $0.106 for every awake CU-hour, so the two cost the same when:

awake CU-hours = $50 / $0.106 = 472 CU-hours a month, or about 15.5 hours a day.

Below roughly 15.5 awake hours a day, Neon Launch is cheaper. Above it, the flat $50 box wins. On the Scale rate ($0.222) the crossover drops to $50 / $0.222 = 225 CU-hours, or about 7.4 awake hours a day, after which the fixed instance is cheaper. This is the same shape you see on any usage-metered compute product, from Fly.io's per-second compute billing to serverless functions: the meter beats a fixed box only while it is genuinely off.

The one lever that fixes an always-on bill

If your Neon bill looks like Bill B, do not upgrade anything. Find what is keeping the compute awake and stop it:

• Point health checks and uptime monitors at a static app route that does not touch Postgres, or space them further apart than the 5-minute suspend window, so the idle timer can actually fire.
• Use Neon's serverless driver (@neondatabase/serverless) or a pooler that drops idle connections, so a long-lived connection is not holding the compute open.
• Set the minimum autoscale size to the smallest that serves your median load, so awake hours cost as little as possible.

Fixing the health-check alone typically drops a "mysteriously always-on" database from roughly 730 awake hours back toward 100, which is the entire distance from Bill B to Bill A. It is the cheapest change on this page and it is a configuration edit, not a migration.

The branching gotcha

Neon's branching is genuinely useful and genuinely mis-budgeted. Branches share storage through copy-on-write, so ten branches of a 10 GB database do not cost you ten times the storage. But each branch with an active compute endpoint bills its own CU-hours. Ten preview branches that wake 2 hours a day at 0.25 CU cost 10 x 0.25 x 2 x 30 = 150 CU-hours, or about $15.90 a month on Launch. The same ten branches kept warm 24/7 by a CI pipeline cost 10 x 0.25 x 730 = 1,825 CU-hours, or about $193.45 a month. Once again it is awake-hours, not branch count, that moves the number, plus $1.50 for every branch past your plan's allowance.

When to self-host instead

For a small, steady, always-on production database, plain PostgreSQL on a $5 to $12 VPS beats every Neon tier on the invoice, because you are paying a flat rate for compute that is awake anyway. What you give up is real: scale-to-zero, instant database branching, and point-in-time restore out of the box (you would run your own backups and WAL archiving). Neon's core is open source (the neondatabase/neon repo), but standing up the full serverless, scale-to-zero, branching stack yourself is a serious operations project, not a weekend swap.

The honest split: for spiky, branch-heavy development workloads with lots of previews and bursty traffic, Neon's scale-to-zero and branching earn their premium. For a single always-on database with steady load, a fixed VPS or a reserved managed instance is cheaper and simpler. This is the same build-versus-buy line that runs through Firebase's usage-metered pricing and every other serverless backend: the serverless premium is worth it exactly when your usage is uneven. If you want to sanity-check the alternative, Supabase's plan-based pricing meters compute differently (fixed monthly tiers plus compute add-ons rather than pure CU-hours), and teams weighing the two swap notes constantly, including this Hacker News thread on migrating off Neon.

Math check: the decisive number on Neon is not your plan and not your data size, it is awake hours. At the Launch rate, every hour your 1 CU database fails to sleep costs $0.106, so a database pinned awake all month by a stray health check burns 730 x $0.106 = $77.38 in compute to serve traffic that would have fit inside a $7 bill. Fix the thing keeping it awake before you touch anything else.