Serverless database pricing compared: what each meter actually counts

Comparing serverless database pricing by headline number does not work, because most of these products do not have a headline number. They have a formula, and the variable in the formula is something your application decides at runtime: how long a query ran, how many rows it scanned to find the ones it returned, how many commands your cache issued during a traffic spike.

So 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.

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

The meters

Everything below is from each vendor's own pricing page or docs, captured in July 2026 and linked in the section that discusses it. Pricing pages move faster than blog posts. Treat this as a snapshot and click through before you plan a budget around any row.

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 daily free allowance covers small projects comfortably and the per-million rate is low, so this is rarely expensive. 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 (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 inactivity and stay restorable for 90 days, after which you can download a backup but not resume the project.

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, from $5 to $5,599 a month on Postgres and $39 to $23,979 on Vitess, with storage, backups, egress, and replicas billed separately. 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 60 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.

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.