Neon Pricing: The Honest Cost of Serverless Postgres

Neon can cost $3 a month, or $680 a month, for the same-sized database. The difference isn’t your data, it’s whether your app ever sleeps.

That swing is what makes Neon pricing hard to pin down. Neon’s serverless Postgres (now a Databricks company) bills by the CU-hour and scales to zero when idle, so it runs almost free for a quiet side project and gets genuinely expensive for an always-on one. This is the honest 2026 breakdown of what you’ll actually pay.

We run managed Postgres at a fixed hourly rate, so we’ve costed Neon against our own stack more times than we can count. The math here is honest, and it cuts both ways.

All rates verified against Neon’s published pricing in August 2026.

Key Takeaways

• The model in one line: Neon is usage-based serverless Postgres. You pay separately for compute (by the CU-hour), storage, branching, and backups. There is no fixed instance fee.
• The 2026 rates: compute is $0.106/CU-hour on Launch and $0.222/CU-hour on Scale, storage is $0.35/GB-month, and there has been no monthly minimum since December 2025 (use $3, pay $3).
• Cheap when idle, costly when not: a scale-to-zero side project can cost a few dollars a month, while a 24/7 production database can run into the hundreds. Same database, very different bill.
• The unit to know: 1 CU (Compute Unit) = 1 vCPU + 4 GB RAM.

Those are the four numbers the rest of this post builds on. If you already know your database is always-on, the comparison that matters is against a fixed instance: Selfhost.dev runs Postgres on the same AWS hardware at a set hourly rate, so a traffic spike does not move the compute line at all. You can have a live database in about two minutes, and pause it zero whenever you want.

How Does Neon Pricing Work?

Neon uses a fully usage-based, serverless pricing model. Instead of renting a fixed database instance by the month, you pay only for what your database actually consumes, measured across four things:

• Compute (CU-hours). You are billed for the time your database is awake and serving queries. One CU is 1 vCPU and 4 GB of RAM, and a CU-hour is one CU running for one hour.
• Storage (GB-months). You are billed for the volume of data you keep, charged per gigabyte per month and metered hourly, so you pay for your average size, not your peak.
• Branching (branch-hours). Every plan includes a set number of simultaneous database branches. You only pay extra if you keep more open at once than your allowance.
• Instant Restore (GB-months). You are billed for the write-ahead log history Neon retains so you can rewind the database to an earlier point in time (point-in-time recovery).

The mechanic that ties it all together is scale-to-zero. After about five minutes of inactivity, Neon suspends your compute entirely and the CU-hour meter stops. The moment a query arrives, the database wakes again in a few hundred milliseconds. That is why an idle database costs almost nothing, and why the same database starts costing real money the moment it stops being idle.

This is the opposite of the fixed-instance model used by traditional managed Postgres like AWS RDS, where you pay for the server whether or not anyone touches it. Usage-based billing flips the deal: you pay for activity, not for capacity sitting on standby.

Neon Pricing Plans: Free, Launch, and Scale (2026)

Neon has three published plans: Free, Launch, and Scale. All are built on the same usage-based model, and none of the paid plans has carried a monthly minimum since December 2025. You pick a plan for its features and limits, not for a fixed price, because the bill still comes from what you use.

One quick accuracy check before you budget: if you are reading an older comparison, verify its numbers. A lot of guides still quote a $5 monthly minimum on Launch, a $69 minimum on Scale, or $0.14/CU-hour compute. All three are out of date. Neon removed the minimums in December 2025 and cut Launch compute to $0.106/CU-hour, so any total built on the old figures is too high.

Free is for proving things, not running them.100 CU-hours and 0.5 GB per project, with scale-to-zero always on. Genuinely useful for prototypes, but the hard usage cutoff makes it unsuitable for production.

Launch is the workhorse. Pay-as-you-go with no minimum, autoscaling to 16 CU, and 10 branches included. This is where most startups and small production apps land.

Scale adds the enterprise checkboxes. Same model at roughly double the compute rate ($0.222/CU-hour), plus SOC 2, HIPAA, a 99.95% SLA, and private networking. You move here when a customer’s security review forces it, not before.

Enterprise is unpublished. Neon offers custom contracts for large deployments, but there are no public rates, so you negotiate directly.

How Much Does Neon Actually Cost Per Month?

Anywhere from about $3 to several hundred dollars, for databases that look identical on paper. The variable is how much your database is actually awake. Three realistic examples (illustrative math, at current Launch and Scale rates):

Side project, scale-to-zero: about $3/month. A hobby app that gets occasional traffic sits suspended most of the day. Say it burns 20 CU-hours of compute (20 × $0.106 = $2.12) and stores 2 GB ($0.70). That is well under $5, and on a truly idle month it rounds down to almost nothing.

Startup staging, business-hours use: about $20 to $36/month. A database active through the working day, idle at night and on weekends. Run 2 CU for 8 hours across 20 days (320 CU-hours × $0.106 = $33.92) plus 10 GB of storage ($3.50), and you are at roughly $36.

Always-on production: about $345 to $683/month. A 4 vCPU / 16 GB database (4 CU) that never sleeps runs 730 hours a month. On Launch, that is 2,920 CU-hours × $0.106 = $309.52, plus 100 GB of storage ($35), or about $345. The exact same database on Scale ($0.222/CU-hour) costs about $683.

That last number is the one that surprises people, and it is worth sitting with. The side project and the always-on production database are the same Neon, billed the same way. The only thing that changed is whether the compute ever got to switch off.

Curious what that same always-on database costs without a meter? Price it in our calculator in about thirty seconds, no signup needed.

You can see how that always-on figure stacks up against other managed Postgres providers in our cost breakdown, where the same workload runs from about $86 to $255 like-for-like, and up to $475 for a full high-availability setup.

Is Neon Expensive? The $680 Question

Honestly, both. Neon is one of the cheapest ways to run Postgres when your database is idle or bursty, and one of the most expensive and least predictable when it is always on. The headline rate never changes. What changes is how many hours you get billed for.

That gap between a quiet month and a busy one has a name we use across our comparisons: Bill Variance. It measures how much a bill moves with your traffic instead of staying put. Flat-rate hosts score near the bottom. Purely usage-based ones score high. Because every Neon compute hour is metered and scales with load, it lands in the high-to-very-high band, alongside Railway and Fly.io. (Full method and scoring: see our bill variance guide.)

A quick rule of thumb:

• Cheap on Neon: idle, bursty, or dev/preview databases that sleep most of the time.
• Expensive on Neon: always-on production databases that never get to scale to zero.

It is easy to feel. A Launch database that costs about $20 in a calm month can climb to roughly $70 the month a launch or a Hacker News feature quadruples your traffic, a swing of about 3.5x off the quiet baseline. Your data did not change. Your bill did.

You see the same thing when developers talk about Neon in public:

• An engineer on r/AskEngineers opened a $19.85 bill for a directory site doing barely 1,500 visitors a month, and called it “terrible value.”
• A startup that left Neon wrote on Hacker News that its usage-based pricing “punished our success,” reaching $250 a month for four databases.

The complaint is rarely that Neon is expensive in absolute terms. It is that the bill moved when they were not expecting it.

In fairness, the model cuts both ways. For idle and spiky apps, not paying for headroom you rarely use is a real saving, and the same scale-to-zero that makes the bill volatile is what makes it almost nothing when no one is online.

The honest rule is not “usage-based bad, flat-rate good.” It is this: high Bill Variance only hurts if a surprise bill would actually be a problem for you. If a database that occasionally triples is a non-event, Neon will save you money. If an unexpected $200 line item is something you would have to explain to someone, the volatility is the real cost, not the rate.

It is the same dynamic that makes AWS RDS bills creep as you grow and hard to forecast charge by charge. And it is not confined to Postgres. ClickHouse Cloud does the same thing to an analytics bill: $66.52 a month at six active hours a day against $186.27 running 24/7, same tier, same data, with uptime the only variable that moved.

Neon at least publishes the rate that moves. ClickHouse’s own managed Postgres charges $23.19 a month for the machine and publishes no rate at all for ingestion, backups or egress, so its bill variance cannot be scored yet, only guessed at. We worked through what ClickHouse Managed Postgres actually costs and what happens when those three meters switch on.

Where Neon’s Bill Surprises You

Five things push a Neon bill past its headline rate. None are truly hidden, but they are easy to miss until the invoice lands.

The pattern: the volatile lines, compute and egress, are the ones tied to how busy you are, and they are the least visible on the pricing page. The figure you budgeted from is really just the quiet-month figure, and our Bill Variance calculator will show you in seconds how far the busy month can drift from it. Either way, the bill to plan around is the high one, not the low one.

Running an always-on Neon database? See it compared against a flat-rate Postgres host on the same AWS hardware. →Neon vs Selfhost.dev

Neon’s Free Tier: What You Get, and Where It Stops

Neon’s free tier is genuinely generous for building and learning, and genuinely unsuitable for running anything real. Both are true, and the line between them is sharp.

What you get, per project, at no cost:

• 100 CU-hours of compute per month
• 0.5 GB of storage
• Autoscaling up to 2 CU
• 10 database branches
• 5 GB of egress

You can run up to 100 projects on the free plan, and it is permanent, not a 30-day trial.

The catch is two-fold. First, scale-to-zero is mandatory: you cannot keep a free database always-on, so it will cold-start after idling. Second, the limits are hard cutoffs, not soft throttles. Hit 100 CU-hours or 0.5 GB and the database suspends until the next cycle or until you move to a paid plan. That is fine for a prototype, a demo, or learning Postgres. It becomes a problem the moment real users depend on the database being awake and inside the limits.

Neon’s 0.5 GB sits at the bottom of the range, level with Supabase and Railway, while Render, Aiven and Koyeb all give 1 GB. The gap matters less than what each one does at its ceiling. Render deletes the database 30 days after creation, Supabase goes read-only at 500 MB, and Aiven powers off and waits for a human to restart it. Six providers offer a genuinely free Postgres tier and every one of them stops in a different way, so the mechanism is what decides whether a free tier is usable, not the gigabyte count.

In practice, the free tier answers “can I build on Neon for free?” with a clear yes, and “can I run production on Neon for free?” with a clear no. When you outgrow it, you do not so much pick a bigger plan as start paying for the usage you were already shaped around, which is where the Launch tier comes in.

Neon Pricing vs the Alternatives

Where Neon lands depends entirely on the shape of your workload. It beats always-on rivals on idle and bursty cost, and it loses to flat-rate options when you are steady-state and need a bill you can predict to the dollar. Here is how the common Postgres choices compare on the axis the pricing pages skip: predictability.

(Bands are by pricing model and illustrative, not measured invoices. See our Bill Variance methodology for the scoring method and full platform rankings.)

That table sorts the models. It does not price them. We did that separately, costing a 2 vCPU, 8 GB, 100 GB Postgres across nine Neon alternatives, where the monthly totals run from $79 to $195.

vs Supabase.

This is the comparison people get wrong most often, because they are not really the same product. Supabase is a backend platform: Postgres bundled with auth, storage, realtime, and edge functions, on a flat $25/month Pro floor. Neon is just the database, billed by usage.

Supabase’s flat fee is actually the more predictable of the two, and the protection runs deeper than the fee: on Pro, spend caps are on by default, so usage throttles instead of quietly generating overage charges. Neon is the cheaper option when your database is idle.

So the pricing question is downstream of a product question, which we untangle in our full Neon vs Supabase comparison.

vs AWS RDS and Aurora.

RDS rents you a fixed instance around the clock, so the rate is predictable, but you pay for it whether or not anyone is querying, and the bill climbs steeply as you size up. Aurora Serverless v2 is a different animal: it autoscales with load, which lands it closer to Neon’s volatility than to a flat instance. Neon’s scale-to-zero wins for bursty and dev workloads that would leave an RDS instance idling, while a steady production instance often costs less on provisioned RDS than on Neon’s Scale tier. We break the real numbers down in our RDS cost comparison and the Hetzner-versus-RDS teardown.

vs self-hosted and predictable Postgres.

If what you actually want is a production Postgres bill you can forecast, the usage meter is the part to remove.

This is where we fit: Selfhost.dev runs managed PostgreSQL from $5/mo on the same AWS instances as RDS, about 67% less on a like-for-like instance, with no scaling penalties and a credit wallet that pauses at $0 instead of handing you a surprise invoice. Compute is a known hourly rate, so the volatile line in a usage-based bill is gone, though storage and egress still move with your data.

Storage is the line that does not move with traffic, and it is where the gap is widest: Neon charges $0.35/GB-month, we charge from $0.08. It also runs in your own AWS account if you want it to, it is drivable from Claude or Cursor over 161 MCP tools, and it carries a 99.9% SLA.

That is low Bill Variance with a hard ceiling, not a meter you hope stays quiet. To see it in numbers, our full Neon vs Selfhost.dev pricing comparison costs that same always-on database, the one that runs about $683/month on Neon, line by line against a flat-rate setup. The broader managed-versus-self-hosted case is here, along with theBYOC model behind it.

How to Predict and Control Your Neon Bill

How to Calculate Your Neon Bill

Four numbers, at current Launch rates. Neon autoscales, so multiplying by the maximum CU you allow gives you the worst case rather than the likely case, which is the figure worth budgeting from.

• Compute ceiling: Max CU × hours awake per month × $0.106. A month is 730 hours.
• Storage: GB stored × $0.35.
• Instant restore: $0.20 per GB-month of retained changes. This is the one line you cannot size in advance. You can only cap it by shortening the restore window.
• Egress: $0.10/GB beyond the first 500 GB per project.

A 2 CU database that is awake for 12 hours a day with 50 GB of data costs:

• Compute: 2 × 365 hours × $0.106 = $77.38
• Storage: 50 × $0.35 = $17.50

That is about $95 per month at the ceiling.

On the Scale plan, replace $0.106 with $0.222. The compute cost becomes $162.06.

You cannot make a usage-based bill flat, but you can put a ceiling on it. Four levers do most of the work:

1. Cap your autoscaling maximum. Your worst-case compute is the max CU you allow times the hours it runs. Set a ceiling you are willing to pay for (a 4 CU cap on Launch holds you to about $0.42/hour) so a spike scales performance, not your invoice past a number you chose.
2. Tune the scale-to-zero timeout. The default suspends after 5 minutes idle. Leaving it on for dev, staging, and preview databases is the single biggest saver, since those sit idle most of the day. Only disable it for databases that genuinely cannot tolerate a cold start.
3. Shorten your restore window. Instant restore is billed at $0.20/GB-month of retained changes. A 30-day window on a write-heavy database stores a lot of WAL. If you do not need a month of history, drop it to a few days and the line shrinks with it.
4. Watch egress. The first 500 GB per project is included, then it is $0.10/GB. Large exports, analytics pulls, or chatty clients in another region are the usual culprits. Keep the database and its app in the same region so ordinary traffic never crosses a billed boundary.

A fifth, if you run many databases: branches and per-project metering add up. Delete branches your CI no longer needs, and consolidate idle projects rather than letting each accrue a baseline.

One caveat for AI workloads: model them before you commit. Embedding-heavy and agent workloads can keep compute awake far more than a typical app, which changes the math entirely, and the same is true of AI tooling that provisions databases on demand.

Is Neon Worth It? Who Should (and Shouldn’t) Use It

Neon is worth it when your workload is bursty, idle-heavy, or development-shaped, and worth reconsidering when it is steady, always-on, and tied to a budget you have to defend.

Choose Neon when:

• Your database is idle a lot. Side projects, internal tools, anything quiet outside business hours. Scale-to-zero means you pay close to nothing for the downtime.
• Your traffic is genuinely spiky and you would rather not pay for headroom year-round.
• You lean on branching. Per-PR preview databases and CI branches are Neon’s standout feature, and they are cheap.
• You run many small or ephemeral databases (multi-tenant, per-customer, agent-provisioned), where always-on instances would cost far more.
• You are early and small, where usage-based often beats the smallest flat plan in absolute dollars.

Reconsider Neon when:

• Your production database is always-on. The scale-to-zero saving disappears and you pay the metered rate around the clock, which is where the Scale tier reaches several hundred dollars a month.
• You need a bill you can forecast. High Bill Variance is the real cost, even when the rate is fair.
• A cold start is unacceptable for your user-facing latency.
• You are storage-heavy and steady, where a fixed instance with cheaper storage can win.

If you read that second list and recognised your workload, the move is not to fight Neon’s meter with tuning, it is to use a pricing model that does not have one. We cost that out line by line, the same always-on database on both platforms, in our Neon vs Selfhost.dev comparison.

The part that stops most teams is not the price, it is the move itself. Neon supports logical replication out, so the data syncs live to an always-on instance and you cut over with near-zero downtime, and small databases move with a plain pg_dump and restore. A Selfhost.dev engineer plans and runs it with you, end to end, at no extra cost. You change the connection string only once a restore has been verified on the new instance.

Already running an always-on Neon database? Send us your project size and Postgres version and we’ll send back the exact fixed monthly figure, plus a migration plan. Free cost audit, no signup.

If you would rather see it running first, a production Postgres instance provisions in about two minutes and pauses the moment you stop it.

The Bottom Line on Neon Pricing

Neon is one of the best-value Postgres databases you can run in 2026, and one of the least predictable. Both halves are true at once, and which one you experience comes down to a single question: does your database ever get to sleep?

For idle, bursty, and development workloads, the answer makes Neon close to unbeatable. Scale-to-zero hands you a bill of a few dollars, branching is genuinely useful, and the usage model works in your favour. For an always-on production database, the same model removes the idle savings, keeps the meter running around the clock, and turns the bill into a number that moves with your traffic instead of one you can plan around. That is the swing from $3 to $680 at the top of this page, and it was never about the size of your data.

So the honest takeaway is not “Neon is cheap” or “Neon is expensive.” It is this: know which workload you have before you commit. If it is bursty, Neon’s variance is a feature. If it is steady and you need a bill you can forecast, that variance is the cost, and a flat-rate host is the fix.

Run your own numbers before you decide. Estimate a flat-rate Postgres bill in our calculator, no signup required. And if you have already met your always-on Neon bill, the line-by-line Neon vs Selfhost.dev comparison shows what the same database costs once you take the meter out.

Ready to skip the surprise bill? Spin up a production-ready Postgres database in under three minutes. Get a connection string in two minutes.

Frequently Asked Questions