Neon vs. Your Own Postgres: Where the Cost Crossover Actually Is
Serverless Postgres bills you for duty cycle, a server bills you for capacity. Here's the math on when Neon stops being the cheap option, and whether it ever makes sense to have customers bring their own Neon accounts.
I run several apps on Neon, each with its own customer databases, and the bill has been creeping up. That prompted an obvious question: at what point do I stop paying for serverless Postgres and just run my own box? And a less obvious one: could I push the database cost onto customers by having them bring their own Neon accounts?
The answer to the first question turns out to hinge on a single variable that most cost comparisons bury, and the answer to the second is “yes, but probably not for the reason you’re hoping.”
The Quick Take
The crossover isn’t about how many databases you have. It’s about duty cycle.
Neon bills you for the compute you actually burn. A server bills you for capacity whether you use it or not. So the question is never “Neon or self-hosted?” in the abstract — it’s “what fraction of the day are my databases actually awake?”
- Databases that are idle most of the time → Neon wins, and it isn’t close. Fifty bursty tenant databases cost about the same as one server, with zero ops.
- Databases that are pinned awake → self-hosting wins, and it isn’t close. Fifty always-on databases cost roughly 25x a single server.
Everything below is the math behind that, plus the caveats that decide it in practice.
How Neon Actually Bills You
Neon’s pricing is simpler than it looks once you know the units. A CU (Compute Unit) is roughly 1 vCPU and 4 GB of RAM. As of mid-2026:
| Free | Launch | Scale | |
|---|---|---|---|
| Compute | 100 CU-hours/project | $0.106/CU-hour | $0.222/CU-hour |
| Storage | 0.5 GB/project | $0.35/GB-month | $0.35/GB-month |
| Projects | 100 | 100 | 1,000 |
| Branches included | 10/project | 10/project | 25/project |
| Egress | 5 GB | 500 GB, then $0.10/GB | 500 GB, then $0.10/GB |
| Max autoscale | 2 CU | 16 CU | 16 CU (fixed to 56 CU) |
| SOC 2 / HIPAA | No | No | Yes (HIPAA costs extra) |
Two things worth flagging, because they changed recently and a lot of blog posts still have the old numbers: storage dropped from $1.75 to $0.35/GB-month, and the $5/month minimum on paid plans is gone. Paid plans are now purely usage-based. That’s a big deal for the database-per-tenant pattern — a dormant tenant genuinely rounds to nothing.
The number that matters is that $0.106/CU-hour. Multiply by 730 hours in a month:
1
2
3
1 CU, always on: 730 × $0.106 = $77.38/month
2 CU, always on: 730 × $0.212 = $154.76/month
4 CU, always on: 730 × $0.424 = $309.52/month
That’s the anchor. A single always-on 1 vCPU / 4 GB Postgres on Neon costs about $77/month. Hold that thought.
Scale-to-zero is the whole product
Neon suspends compute after 5 minutes of inactivity, and suspended compute bills $0. This is not a footnote — it’s the entire economic argument for Neon, and it’s why the “Neon is expensive” takes are usually wrong.
A tenant database that’s genuinely used one hour a day at 1 CU burns 30 CU-hours a month. That’s $3.18. You could run 20 of those for $64/month. On a server, those same 20 databases cost you a full box whether anyone logs in or not.
The flip side is that disabling scale-to-zero flips Neon from cheap to expensive in one click. If you’ve turned it off to dodge cold starts, you’ve opted out of the thing you’re paying a premium for, and you should read the rest of this post carefully.
What a Server Costs Now (This Changed in June)
Here’s the part that shifted the math this year. Hetzner raised cloud server prices on 15 June 2026 — dedicated vCPU instances went up 2.1x to 2.7x, driven by a DRAM market shock (memory is up around 171% year over year on AI demand) and more expensive NVMe.
| Model | vCPU | RAM | Old (€/mo) | New (€/mo) |
|---|---|---|---|---|
| CCX13 | 2 | 4 GB | 15.99 | 42.99 |
| CCX23 | 4 | 8 GB | 31.49 | 85.99 |
| CCX33 | 8 | 16 GB | 62.49 | 138.49 |
| CCX43 | 16 | 32 GB | 124.99 | 275.99 |
| CCX53 | 32 | 64 GB | 249.99 | 533.49 |
(Ex-VAT, IPv4 extra. Existing servers keep their old terms — this hits new orders and rescales.)
This matters because the standard “just self-host on Hetzner, it’s 10x cheaper” advice was calibrated on the left column. Take the CCX33: 8 vCPU / 16 GB, which is roughly 4 CU worth of RAM.
- Before June: €62.49 (~$68) vs. $309/month for 4 always-on CU on Neon → 4.5x cheaper to self-host
- After June: €138.49 (~$151) vs. $309/month → 2x cheaper to self-host
A 4.5x gap is worth building a runbook for. A 2x gap, before you’ve counted a single hour of your own time, is not obviously worth anything.
The Actual Crossover Formula
Here’s the model I settled on:
1
2
Neon ≈ $77.38 × (average CU across the month) + $0.35 × GB stored
Self-host ≈ box cost + (ops hours/month × your hourly rate)
The critical term is average CU, not peak CU. Autoscaling and scale-to-zero mean you pay for the area under the curve, not the height of it. Peak 4 CU at 20% duty cycle is 0.8 average CU — about $62/month, not $309.
Running the break-even against that CCX33 at ~$151/month:
- If your ops time is free: $151 ÷ $77.38 ≈ 1.95 average CU. Above roughly 2 sustained CU, the server is cheaper.
- If you price ops honestly: even 2 hours/month at $100/hour is $200, making the true cost ~$351/month ≈ 4.5 average CU.
And two hours a month is an optimistic number for something that holds your customers’ data. It has to cover backups you’ve actually tested restoring, monitoring, connection pooling, minor version upgrades, disk-full incidents at 2am, and the tail risk that you are now the only person who knows how any of it works.
So the honest crossover is somewhere around 4–5 sustained CU-average, and it only counts if you have someone who will genuinely do the ops. Below that, self-hosting is a way to convert money you weren’t spending into work you now have to do.
The number that should actually scare you
Duty cycle dominates everything else. Same 50 tenant databases, two scenarios:
| Scenario | Neon | One CCX33 |
|---|---|---|
| 50 tenants, ~1 hr/day active (bursty) | ~$160/mo | ~$151/mo |
| 50 tenants, always-on 1 CU | ~$3,870/mo | ~$151/mo |
Same database count. 25x difference in the verdict. This is why “how many customers do you have?” is the wrong question and “are your databases awake right now?” is the right one.
If you’re in the top row, Neon is free money — you get provisioning APIs, branching, and point-in-time recovery for roughly the price of the server, minus all the work. If you’re in the bottom row, you are lighting money on fire and have been for months.
Should Customers Bring Their Own Neon Accounts?
This is technically real, and I was surprised how real. Neon has a claimable database flow and a project-transfer API: you provision a fully-configured project on the customer’s behalf, then hand them a claim link. They create a Neon account (or use an existing one), claim it, and own it outright. It’s part of the Neon Partner Program, currently in private preview.
So the mechanism exists. Whether you want it is a different question.
The case for it
- The cost leaves your P&L entirely. Not marked up, not passed through — just gone.
- You dodge the project ceiling. Launch caps at 100 projects and Scale at 1,000 (soft). If you’re provisioning a database per customer, that’s a real wall, and it arrives sooner than you’d think.
- Compliance stops being your problem. The customer’s data is in the customer’s account under their own SOC 2 / HIPAA posture. For regulated buyers this converts an objection into a selling point.
- It’s a trust story. “Your data lives in your account and you keep it if you fire us” closes deals that “trust us, we back it up” doesn’t.
- Clean offboarding. Agencies especially: the handoff at end-of-engagement is a link, not a migration project.
The case against it
- Support costs will eat the savings. You now debug problems inside infrastructure you can’t see, on plans you don’t control, with a customer who upgraded their compute to 16 CU and wants to know why their bill tripled.
- You lose migration control. Rolling a schema change across N customer-owned projects with independent Postgres versions and settings is materially harder than across N projects you own.
- Onboarding friction is brutal. Every self-serve signup now includes “go create a Neon account and add a credit card.” Your conversion funnel will notice immediately.
- No cross-tenant anything. Aggregate analytics, fleet-wide migrations, usage-based billing, “which tenants are on the old schema” — all much harder.
- You forfeit volume leverage. Fifty small accounts each pay retail. One consolidated account is where negotiating power lives.
- SLA math stops working. You can’t credibly promise uptime for a database whose owner can suspend, downgrade, or delete it.
The verdict
BYO databases are an enterprise and agency feature, not a cost-reduction strategy. Reach for it when the customer wants to own the data — regulated industries, data-sovereignty requirements, agency handoffs, anyone with a procurement team. Those customers will pay more for it, not less, and they’ll be happier.
Do not reach for it to shave your bill on self-serve SMB customers. You’ll trade a predictable line item for unpredictable support load, and support load doesn’t show up on the invoice you were trying to shrink.
What I’m Actually Doing
- Staying on Neon for everything bursty, which is most of it. Fifty dormant tenant databases costing $160/month with a provisioning API and branching included is not a problem worth solving.
- Auditing which computes have scale-to-zero disabled. This is the single highest-leverage thing on the list. Every always-on compute is a ~$77/month standing order, and some of them are almost certainly awake for no reason.
- Watching for any single tenant that goes sustained-hot. The moment one database is legitimately awake all day at multiple CU, it gets moved to a dedicated box — but just that one, not the whole fleet.
- Keeping BYO in the back pocket for enterprise deals, priced as a premium feature rather than a discount.
Key Takeaways
- Duty cycle is the whole ballgame. Neon bills for area under the curve; a server bills for the curve’s ceiling, permanently. Everything else is a rounding error.
- The magic number is ~$77/month — one always-on CU on Neon Launch. Any always-on compute is that much per month, forever. Count them.
- The crossover is roughly 4–5 sustained CU-average, once ops time is priced honestly. Below that, self-hosting buys you work, not savings.
- Hetzner’s June 2026 increase moved the goalposts. Dedicated vCPU went up 2.1–2.7x, cutting the self-hosting advantage on a mid-size box from ~4.5x to ~2x. Advice written before June is stale.
- Scale-to-zero disabled = Neon’s value proposition disabled. If you’ve turned it off, either turn it back on or accept that you’re paying serverless rates for a server.
- Database-per-tenant is cheap on Neon specifically because dormant tenants are free — but mind the 100-project cap on Launch and 1,000 on Scale.
- Customer-owned Neon accounts are a trust and compliance feature, not a discount. Sell it to enterprises; don’t inflict it on self-serve.
Resources
- Neon Pricing and plan comparison
- Claimable database integration guide — the BYO handoff flow
- Neon Partner Program
- Hetzner price adjustment, 15 June 2026
- Managed PostgreSQL comparison 2026 — broader provider survey