Serverless database pricing compared: what each meter actually counts
Short version: there is no cheapest serverless database, because most of these products do not have a price, they have a formula. Neon bills compute in CU-hours at $0.106 to $0.222 depending on plan. Aurora Serverless v2 bills ACU-hours between a floor you set and a ceiling you set. Cloudflare D1 bills rows scanned, not rows returned. Upstash bills commands at $0.20 per 100,000. Turso bills rows read past a quota. Supabase and PlanetScale look flat and then meter compute, storage, egress and replicas on top. The variable in every one of those formulas is something your application decides at runtime, so the only comparison worth doing is your own workload against each meter. We charge a flat monthly price with no meter, which is a different trade and not a free lunch: the trade is written out below.
Contents
- The meters
- Neon: compute units and the two-axis bill
- Aurora Serverless v2: capacity units with a floor you set
- Cloudflare D1: rows scanned, not rows returned
- Upstash: commands, which is what a cache does
- Turso: row reads on the SQLite side
- Flat plans with a meter bolted on
- What we charge, and what flat costs you
- How to actually compare these
- FAQ
- Where to start
This post is not a table of monthly prices. It is a table of meters, because the meter is the thing you are actually buying, and it is the thing that will surprise you.
I run Layerbase, which charges a flat monthly price with no meter at all. That is a position, not a neutral vantage point, so I have kept the competitor numbers close to their own pricing pages and linked every one of them.
The meters
Everything below is from each vendor's own pricing page or docs, and linked in the section that discusses it. Competitor rates verified 2026-08-25 from neon.com, developers.cloudflare.com, upstash.com, turso.tech, supabase.com, planetscale.com and railway.com. Aurora is the exception: its rates are per region and per engine, so the only correct number is the one on the AWS page for your region. Pricing pages move faster than blog posts, so treat this as a snapshot and click through before you plan a budget around any row.
| Vendor | What the meter counts | The number your code moves without telling you |
|---|---|---|
| Neon | Compute in CU-hours, storage per GB-month, egress per GB | How many CU-hours a month of real traffic burns |
| Aurora Serverless v2 | ACU-hours between a minimum and maximum you configure | Where the autoscaler actually settles under load |
| Cloudflare D1 | Rows read and rows written | A query plan that stops using an index |
| Upstash | Commands, plus storage per GB | Cache hit rate, retries, health checks |
| Turso | Rows read, past a per-plan quota | Any scan-heavy query |
| Supabase | Flat plan plus metered compute, storage, egress, MAU | Preview branches, which bill separately |
| PlanetScale | Flat per cluster size plus storage, backups, egress, replicas | Cluster size, once you have to go up one |
| Layerbase | Nothing | Nothing |
Neon: compute units and the two-axis bill
Neon separates storage from compute, which is the architectural reason it can bill them separately and scale compute to zero. Their published model has no minimum: compute runs from $0.106 to $0.222 per CU-hour depending on plan, storage is $0.35 per GB-month, and egress is $0.10 per GB (plans). The free tier is 100 CU-hours plus 0.5 GB of storage and 5 GB of transfer per project per month, and when you exceed it compute suspends rather than data disappearing: "None of these limits delete your data".
A CU-hour is a compute unit running for an hour, so the bill is a product of how big your compute is allowed to get and how long it stays awake. Both halves are set by traffic. A database that wakes for every request from a serverless function is awake far more than the request count suggests, because there is a hold-open window after each one. This is not a Neon problem specifically, it is the shape of compute-time metering, and it is why the first month on a metered plan is a measurement exercise rather than a budget.
Branching is priced on the same axis: 10 branches per project on the free plan, then $1.50 per branch-month (branching). If you are evaluating Neon on the product rather than the price, Neon vs Supabase covers the feature comparison, and their own site is at Neon.
Aurora Serverless v2: capacity units with a floor you set
Aurora Serverless v2 measures capacity in Aurora Capacity Units and bills per ACU-hour, with a minimum and maximum capacity you configure on the cluster. Rates vary by region and engine, so the number to read is the one on the Aurora pricing page for your region rather than any figure quoted in a blog post, including this one.
The structural thing to understand is that the minimum capacity setting is a floor on your bill as well as on your performance. Everything else about it is normal RDS: it lives in a VPC, it bills I/O and storage and backups on their own lines, and it is a genuinely serious production database. It is serverless in the sense that you are not choosing an instance type. It is not serverless in the sense of "sign up and get a URL", and it is not aimed at people who want that.
Cloudflare D1: rows scanned, not rows returned
D1 meters rows read and rows written, and the definition is the part to internalize: rows read "measure how many rows a query reads (scans), regardless of the size of each row".
Scans, not results. A SELECT that returns three rows after scanning two million bills for two million. That makes indexing a cost decision rather than only a latency one, and it means a schema change or a query-planner shift can move your bill without anyone editing a pricing page. The free plan allows 5 million rows read and 100,000 rows written a day, and on the paid plan the first 25 billion monthly row reads are included and the rest are $0.001 per million, so this is rarely expensive in absolute terms. It is unpredictable in a specific way that flat pricing is not, and if your access patterns include a full-table scan anywhere, find it before it finds you. The wider coupling story is in Cloudflare D1 alternatives.
Upstash: commands, which is what a cache does
Upstash charges $0.20 per 100,000 commands plus $0.25 per GB of storage, or you can move to fixed plans that start at $10 a month (pricing). The free allowance is 256 MB, 500,000 commands a month, and 10 GB of bandwidth.
Per-command pricing is a genuinely good fit for spiky, mostly-idle workloads, and the REST API means it works from runtimes that cannot open a socket. The tension is that Redis is at its best when it is hit constantly. A read-through cache on a page with real traffic is a command counter running at full speed by design, and 500,000 a month works out to roughly 11 commands a minute sustained. Not a criticism of the product, just a mismatch worth checking against your own workload shape. I compared the free Redis tiers on exactly this axis in Redis free tiers compared.
Turso: row reads on the SQLite side
Turso's tiers are flat plus per-row overages: free at $0, then a $4.99 entry plan, with reads past the included quota billed at $1.00 per billion on that plan and less on larger ones (pricing). Free includes 5 GB of storage, 500M rows read and 10M rows written per month, and 100 databases.
Row-read metering has the same property as D1's, which is that the meter is downstream of your query plan rather than your traffic. The other number worth knowing is behavioral rather than financial: free databases are archived after 10 days of inactivity, restorable through the unarchive endpoint rather than deleted. More in Turso alternatives.
Flat plans with a meter bolted on
Two vendors sit in between, which is the model most likely to catch you out, because the headline number looks like the whole price.
Supabase charges $0 for free and $25 a month for its paid tier, and then meters compute, storage, egress, and monthly active users on top: storage past 8 GB at $0.125 per GB, egress past 250 GB at $0.09 per GB, and MAU past 100,000 at $0.00325 each (pricing). Preview branch compute starts at $0.01344 per hour and, per their own docs, branches are not covered by the spend cap. Free projects pause after one week of low database activity and can be resumed from Studio for up to a year, though their docs are candid that backups age out and older ones may not be compatible with the current platform.
PlanetScale has no free plan at all: Hobby closed to new databases in March 2024 and retired that April, and their current docs state it plainly (plans). Pricing is flat per cluster size, starting at $5 a month for a single-node PS-5 Postgres cluster ($15 for the three-node HA version) and climbing past $47,000 for the largest metal SKU, with the Vitess line running $39 to $23,979. Storage, backups, egress, and replicas are billed separately on all of them. Flat per cluster is predictable right up to the moment you outgrow a size, at which point the step is a step rather than a slope. PlanetScale free tier alternatives covers where people went after Hobby.
Railway deserves a mention because it comes up in these comparisons and is the purest metered model on the list: per second, at $0.00000386 per GB-second of memory and $0.00000772 per vCPU-second, plus volume and egress (pricing). Their databases are also templates you operate yourself, which is a separate conversation I had in Railway databases are unmanaged.
What we charge, and what flat costs you
Free is $0 with no credit card and no expiry date: 2 databases, 5 GB of storage, 8 engines. Solo is $5 a month. Pro is $15 a month. If you need more RAM and vCPU than a plan's pool provides, capacity is added in $10/mo pool blocks rather than by moving you onto a meter.
That is the entire pricing model. No per-query charge, no per-row charge, no compute-second line, no separate egress bill on the plan tiers. The bandwidth allowances published on our acceptable use page are exactly that: an acceptable-use policy with a grace window, not a meter that turns into an invoice.
Flat pricing is not free of trade-offs, and here they are. Free databases hibernate after 15 idle minutes and paid ones after 6 hours, so a first connection to a sleeping database takes roughly 1 to 5 seconds before your query runs normally. Free databases idle for 14 days get archived, which needs an explicit Restore of about 10 to 30 seconds to come back; paid databases are never auto-archived. And a plan is a plan: you get the pool it comes with, and going past it is a plan change you make deliberately rather than a number that grows on its own. That last one is the actual trade. A meter adapts to a spike automatically and charges you for it. A flat plan does not adapt automatically, and does not charge you for it either.
Why we can do this at all is the same architecture the metered vendors use, pointed at a different conclusion: a hibernating database holds no RAM and no CPU, so an idle fleet costs close to storage. I wrote the full economics in the free tier that stays, and the architecture behind serverless databases on our side is written up there.
How to actually compare these
Do not compare list prices. Compare each vendor's meter against your own workload, and do it before you migrate rather than after.
Pick three traffic levels: what you have now, ten times that, and whatever a bad week looks like. For each metered vendor, work out the meter's input at all three. CU-hours means "how many hours a day is compute awake, at what size". Rows read means "run EXPLAIN on your five hottest queries and add up what they scan". Commands means "requests per second times cache operations per request, times a month".
That exercise takes an afternoon and it tells you something a pricing table cannot: whether your bill is stable in the shape your application actually has. If the answer at ten times traffic is a number you would not sign off on, a flat plan is worth the hibernation trade. If your usage genuinely swings by orders of magnitude and idles most of the month, a meter is the fairer deal and you should take it.
FAQ
Which serverless database is cheapest?
Wrong question, and the reason it is wrong is the whole post. Cheapest depends on which meter your workload runs up, and the meters are not comparable to each other. A spiky app that idles 28 days a month is cheapest on a per-command or per-CU-hour meter, because it barely moves the counter. A steady app with a scan-heavy query is cheapest on a flat plan, because on a metered plan that query is a line item forever. Price your own traffic against each formula, not the headline.
What is a CU-hour, and how many will I use?
A compute unit running for an hour. Neon bills them at $0.106 on Launch and $0.222 on Scale, and the Free plan includes 100 a month per project. The count is a product of how large your compute is allowed to scale and how many hours it stays awake, and the second half is the one that surprises people: a database woken by serverless functions stays up through a hold-open window after each request, so it is awake far more than the request count suggests.
Why does Cloudflare D1 charge for rows my query did not return?
Because the meter counts rows scanned. Their docs put it plainly: rows read "measure how many rows a query reads (scans), regardless of the size of each row." A query returning three rows out of a two-million-row table scan bills two million. It makes indexing a billing decision as well as a latency one.
Does a flat plan just hide the meter somewhere?
No, but it charges you in a different currency: flexibility. On our plans there is no per-query, per-row, per-connection or per-compute-second line, and the bandwidth numbers on the acceptable use page are a policy with a grace window rather than an invoice. What you give up is automatic headroom. A meter absorbs a spike and bills you for it; a flat plan does not absorb it and does not bill you for it, so going past your pool is a plan change you make on purpose.
Do free tiers on metered platforms delete my data when I run out?
Generally no, they stop the compute. Neon says it directly: exceed the free allowances and compute suspends, and "None of these limits delete your data". The behavior worth checking is not deletion but recovery, because pausing, archiving and expiring are three different products. Free database tiers that sleep, pause, or expire sorts them.
How do I estimate the bill before I migrate?
Pick three traffic levels: today, ten times today, and a bad week. Then compute each vendor's meter input at all three. For CU-hours, that is hours awake times compute size. For rows read, run EXPLAIN on your five hottest queries and add up the scans. For commands, requests per second times cache operations per request times a month. It takes an afternoon and it answers the only question a pricing table cannot: whether your bill is stable in the shape your application actually has.
Where to start
Create a free database if you want the flat side of that comparison with no card, or read the pricing page for what each plan includes.
Keep reading
- Preview environment platforms in 2026: what is in the database when the preview comes upEvery platform on this list will give a pull request its own URL. The question that sorts them is what is in the database behind that URL: nothing, a restore of last night's backup, or the live data as of right now. Here is where each of eleven platforms lands, quoted from their own docs, and what a preview costs while the PR sits open.
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.
- Redis Cloud alternatives: pay for the modules, or stop paying for themRedis Cloud prices itself around the module story: search, JSON, time series, vector sets, Active-Active. If you use those, the bill is buying something real. If you use Redis as a cache, a session store, or a queue, you are paying the module premium for a key-value store. Here is what each tier buys, where a flat plan fits, and when to stay.
- Neon alternatives: when the CU-hour meter stops matching the workNeon is excellent serverless Postgres with a bill shaped like compute-hours and branch-months. That shape fits a bursty production app and fights a stack of small, mostly idle databases. Here is what Neon actually is, where the meter bites, the current plan numbers, and an honest list of reasons to stay.