Neon Pricing Explained: What Serverless Postgres Costs

Neon is serverless PostgreSQL - the database engine is standard Postgres, but compute is decoupled from storage, scales automatically, and suspends when idle. Its pricing follows that architecture: on the paid plans there is no monthly plan fee at all. The entire bill is usage, spread across four meters. That makes Neon either remarkably cheap or quietly expensive, depending entirely on the shape of your workload - and this article is about knowing which one you are.

The one idea that decides your bill

Before the tables, the mental model. Usage-based compute is a taxi meter; a flat plan is a monthly travel pass. The meter is unbeatable for three short trips a week and ruinous for commuting daily. A CU-hour is that meter, and an always-on production database is the daily commute. Every surprising Neon invoice in this article reduces to that one sentence - somebody bought a meter for a commute.

Two details make the meter run faster than people expect. The first is autoscaling: the rate is per CU-hour, not per clock hour, so a database that scales to 4 CU during a nightly import burns 4 CU-hours every hour it stays there - a two-hour job costs 8 CU-hours, not 2. The second is branch storage: ten preview branches left open after their pull requests merged bill as ten branch-months plus whatever storage has diverged, which is how a quiet month ends up costing more than the busy one before it.

The plans in one table

Scale's higher CU-hour rate buys enterprise features - SOC 2 reports, HIPAA, private networking, a longer restore window - not faster compute. Most individual developers and small teams belong on Launch.

The free tier, honestly

Neon's free tier is one of the better ones in the industry: 100 CU-hours and 0.5 GB of storage per project, autoscaling up to 2 CU, ten branches, and no credit card or expiry date. 100 CU-hours is roughly three hours a day at 1 CU - plenty for a development database or a small demo that sleeps between visits.

The two limits that actually end free-tier tenancies are storage (0.5 GB fills quickly once indexes and WAL are counted) and the suspend behaviour: the first query after an idle period pays a cold start of up to a few seconds. If either has started to hurt, you are the target audience for the rest of this article - and if you are weighing the free tiers against each other rather than against paid plans, Neon vs Supabase covers how the two products differ beyond price.

You can check what your endpoint is actually doing - and whether something is keeping it awake - straight from SQL:

-- how big is this database, really?
SELECT pg_size_pretty(pg_database_size(current_database()));
​
-- what is connected right now (the thing preventing suspend)?
SELECT application_name, state, count(*)
FROM pg_stat_activity GROUP BY 1, 2;

Meter 1: compute, the one that matters

A CU is 1 vCPU plus 4 GB of RAM. Neon autoscales the CU count with load and suspends the endpoint entirely after a few minutes of inactivity. You are billed per CU-hour actually run: a database that autoscales to 4 CU for a busy hour burns 4 CU-hours in that hour; a suspended database burns nothing.

This is the whole game. If your database sleeps most of the day - a dev environment, a demo, an internal tool - compute rounds to pocket change. If something keeps the endpoint awake 24/7, you are paying for 730 CU-hours a month minimum: about $77 on Launch at 1 CU, $155 at 2 CU. The classic mistake is an uptime monitor or a cron job that pings the database every minute, silently converting a spiky workload into an always-on one.

Meter 2: storage

Storage bills at $0.35 per GB-month on both paid plans, measured on the actual data size. A 20 GB production database is $7/month - genuinely cheap. The subtlety is that branches share storage via copy-on-write: a fresh branch costs almost nothing, but as the parent and child diverge, the delta is billed too. Stale long-lived branches are how a 20 GB database ends up billing for 35 GB.

Meters 3 and 4: branches and egress

Extra branches past the included 10 cost $1.50 per branch-month, prorated hourly - trivial if you clean up preview branches, real money if every PR leaves one behind. Egress past 500 GB bills at $0.10/GB, which almost nobody hits from a typical app; treat it as protection against pathological cases rather than a line item to model. Instant restore history is the quiet fourth-and-a-half meter: $0.20 per GB-month of retained change history, which write-heavy databases accumulate faster than expected.

Two worked examples

• A side project with traffic spikes. Awake perhaps 3 hours a day at 1 CU, 2 GB of data: ~90 CU-hours (~$9.50) + $0.70 storage = about $10/month. Cheaper than almost anything else with these features, and $0 in a month where nobody visits.

• A production SaaS, always on. 1 CU around the clock with bursts to 2 CU, 15 GB of data, a few preview branches: ~800 CU-hours (~$85) + $5.25 storage + a few dollars of branches = roughly $92 - 95/month. At this point you are paying serverless rates for a server that never stops.

When Neon's model wins, and when it loses

Neon is the right economics when compute genuinely idles: development databases, previews per pull request, demos, internal tools, anything bursty. The branching workflow is excellent and honestly priced. It is the wrong economics for a steady always-on production database, where the meter never stops and a predictable flat bill is both cheaper and easier to forecast.

Full disclosure, since we sell the alternative: Swyftstack's managed Postgres is flat-priced - $19/month with backups and pooling included, no CU-hours, no suspend, no meters. For the always-on case above, that is the same database at a fifth of the price. For the spiky case, Neon's free tier beats us at $0, and we would rather tell you that than have you find out. We ran the same exercise on Supabase's pricing and Railway's if you are comparing the usage-based platforms against each other, and compared the products themselves in Neon vs Supabase.

Work out your own break-even in two minutes

Comparisons usually stop at "it depends on your workload", which is true and useless. Here is the arithmetic instead. Neon's compute bill is:

monthly compute $ = hours_awake  x  average_CU  x  rate
​
Launch rate = $0.106 / CU-hour
A month     = 730 hours

So the only two numbers you need are how many hours your database is actually awake and what CU it settles at while it is. Everything else - storage at $0.35/GB-month, branches at $1.50 each, egress past 500 GB - is rounding by comparison for most applications.

Set that against a flat plan and the crossover falls out. Against a $19/month flat plan that includes storage and backups, the break-even is roughly 179 CU-hours ($19 / $0.106). At 1 CU that is about 6 hours of wakefulness a day; at 2 CU it is 3 hours. Below that, the meter wins. Above it, the pass wins - and an always-on database is 730 hours, four times past the line before storage is counted.

Two honest caveats. Idle does not always mean suspended - a health check, an uptime monitor or a cron job hitting the database every few minutes keeps compute awake all day, so measure observed wake time rather than the traffic you imagine. And autoscaling means the CU column is an average, not a setting: if you scale to 4 CU for two hours a night, add those 8 CU-hours before comparing.

How to keep a Neon bill small

• Let it suspend. Audit anything that pings the database - health checks, cron, keep-alive hacks. Point them at your app, not your database.

• Cap autoscaling at the smallest CU ceiling that survives your real traffic; test with the ceiling low.

• Delete merged branches. Automate it in CI so preview branches die with their PRs.

• Watch the storage graph monthly. Divergent branches and bloat both show up there first.

Prices quoted here were checked in July 2026. Vendors change them; treat the structure as the durable part and re-check the current numbers before you budget.