Cloudflare D1 vs Turso vs PlanetScale: Real Serverless Database Cost for an AI SaaS at 100 Million Queries in 2026
The short answer: PlanetScale's row-based Scaler pricing — the model most older comparisons (and an earlier version of this one) use to price it — no longer exists. PlanetScale fully deprecated the Scaler plan, migrating every remaining customer to the resource-based Scaler Pro plan (now simply called Base), which bills by provisioned compute SKU, storage, and egress — not by rows read or written at all. This means "100 million queries" does not translate into a PlanetScale invoice the way it does for Cloudflare D1 or Turso; PlanetScale's bill depends on which compute tier you provision, not on how many queries you run against it, as long as the tier can handle the throughput. Cloudflare D1 remains the cheapest of the three at roughly $54/month for this article's illustrative workload, because its free included allowance (25 billion rows read a month) swallows the entire read volume with room to spare. Turso lands at about $105/month, driven mainly by its write-row overage. PlanetScale's cost for this specific 100-million-query workload is genuinely UNKNOWN without a capacity-sizing exercise: no published formula connects query or row volume to a required compute SKU, so this article cannot responsibly claim any configuration is "sized" to handle this workload's throughput. What can be stated is a verified configuration-price example — a production-grade 3-node HA Vitess cluster's base compute, independent of whether it happens to fit this article's query volume, prices at roughly $45/month — offered here purely as a reference point for what PlanetScale's pricing shape looks like, not as a recommendation or a sizing claim.
First, verify the premise: does each product still fit the comparison?
Cloudflare D1 remains an active, actively-documented serverless SQLite product with no material repositioning found. Turso remains an active serverless libSQL (SQLite-compatible) product with a generous, stable free tier. PlanetScale requires the most explanation of the three: it eliminated its free Hobby tier in April 2024, and more significantly, fully deprecated its row-metered Scaler plan, migrating all remaining customers to the resource-based Scaler Pro plan (since folded into a plan simply called Base). PlanetScale has also expanded into a separate Postgres product line (postgres_single, from $5/month) alongside its original MySQL-compatible, Vitess-based architecture — this article models the Vitess/MySQL line specifically, since it is the product most architecturally comparable to D1's and Turso's SQLite-family design.
The billing-unit mismatch, up front
Cloudflare D1 and Turso both meter rows read and rows written — not raw query count, since a single query can touch anywhere from one row to millions depending on indexing. PlanetScale no longer meters rows at all. Its current Base plan bills by compute SKU (instance size and topology), storage (GB, with a per-instance included allowance), egress (GB, also with an included allowance), and backups (GB) — a provisioned-capacity model closer to renting a sized database server than to paying per operation. This is not a minor pricing difference; it means PlanetScale's cost for "100 million queries" cannot be derived the same way D1's or Turso's can, and forcing it into a row-based framework to make the three directly comparable would describe a product PlanetScale no longer sells.
What each vendor bills
Cloudflare D1 (OFFICIAL, developers.cloudflare.com/d1/platform/pricing). Rows read: first 25 billion/month included, then $0.001 per million rows beyond that. Rows written: first 50 million/month included, then $1.00 per million. Storage: first 5 GB included, then $0.75/GB-month. Row size does not affect counting — a 1 KB row and a 100 KB row both count as one row read or written. Writing to an indexed column adds an additional written row (one for the table, one for the index). Workers compute that queries D1 bills separately under standard Workers pricing, on top of D1's own row-based charges.
Turso (OFFICIAL, turso.tech/pricing, checked July 2026). Free: 500 million rows read/month, 10 million rows written/month, 5 GB storage, up to 100 databases. Scaler: $24.92/month, includes 100 billion rows read, then $0.80 per billion rows read, $0.80 per million rows written, and $0.50/GB storage beyond included allowances. Turso counts rows read the way SQLite scans them internally — a query without a useful index can generate far more "rows read" than the number of rows actually returned to the application.
PlanetScale (OFFICIAL, planetscale.com pricing and PlanetScale's own product announcements, current as of mid-2026). The Scaler plan — the row-read/row-write-metered product this comparison previously used — was fully deprecated, with all remaining customers migrated to the Scaler Pro cluster-size model, which is now presented simply as the Base plan. Base: no per-seat fee; self-serve, resource-based pricing starting at $5/month for a single-node instance (suited to development or low-traffic workloads, not production), scaling through named compute SKUs up to a Metal tier at $50/month (dedicated NVMe storage for high-performance needs). A production-grade topology uses 3 nodes (1 primary, 2 replicas) across 3 availability zones, reported to cost roughly 3x the single-node price for an equivalent compute SKU. Storage: 10 GB included per instance, then $0.50/GB. Egress: 100 GB included, then reported around $0.06/GB beyond that. Backups: $0.023/GB. None of these meters respond to query count, row-read count, or row-write count — PlanetScale's current pricing page has no equivalent to D1's or Turso's per-row rate at all.
Normalizing the workload: 100 million queries, 90/10 read/write split, 10 GB database
All ILLUSTRATIVE. This article assumes 90 million read queries and 10 million write queries a month, each touching an average of 10 rows — giving 900 million rows read and 100 million rows written — against a 10 GB database. This normalization applies directly to D1 and Turso, both row-metered; it does not directly determine a PlanetScale invoice, for the reasons above.
Cost at this workload
Formula: D1 = max(0, rows read − 25B) ÷ 1M × $0.001 + max(0, rows written − 50M) ÷ 1M × $1.00 + max(0, GB − 5) × $0.75; Turso Scaler = $24.92 base + (rows written ÷ 1M × $0.80), with reads fully covered by the 100-billion-row included allowance; PlanetScale has no row-based formula to apply, and no published query-to-SKU sizing formula either — its cost is a function of which compute SKU and topology an account provisions, and this article cannot verify which SKU would actually be required for this specific workload's throughput and latency needs.
| Platform | Basis | Monthly cost |
|---|---|---|
| Cloudflare D1 | $0 reads (900M well under 25B free) + $50 writes (50M billable beyond 50M free) + $3.75 storage (5GB billable beyond 5GB free) | $53.75 |
| Turso, Scaler | $24.92 base + $80.00 (100M rows written at $0.80/M, reads fully covered by the 100B included allowance) | $104.92 |
| PlanetScale, Base — cost at this specific 100-million-query workload | No published formula connects query volume to required compute SKU | UNKNOWN without a direct capacity-sizing exercise |
| PlanetScale, Base — a verified configuration-price example, not a sizing claim | A production-grade 3-node HA Vitess topology (1 primary, 2 replicas), priced at roughly 3x the $15/month Vitess entry rate for an equivalent single-node SKU | ~$45/month in base compute (confirmed rate math; whether this specific topology actually handles this article's query volume is not established) |
The distinction in the table above matters: the $45/month figure is a real, verifiable price for a named configuration, not a claim that this configuration is the right size for 100 million queries a month. PlanetScale's own calculator, using your actual query complexity, concurrency, and latency requirements, is the only reliable way to determine which SKU a given workload actually needs — this article does not have access to a published mapping between query volume and required compute tier, and presenting one would mean inventing a sizing claim the available sources don't support.
Why query efficiency still matters on D1 and Turso, but not on PlanetScale's bill
Formula: rows touched per query directly multiplies into billed rows on D1 and Turso. This article's illustrative 10-rows-per-query assumption is a rough average; a query hitting an unindexed column can scan far more rows than one using a proper index, and on either rows-read-billed platform, that difference shows up directly in the bill. On PlanetScale's current Base plan, the same inefficient query pattern doesn't generate a bigger invoice directly — it instead demands more compute headroom from the provisioned SKU to maintain acceptable latency, which can indirectly force an upgrade to a larger, pricier cluster tier, but there is no per-row charge translating inefficiency into cost the way D1's and Turso's meters do.
Sensitivity
- Rows touched per query (query efficiency), for D1 and Turso specifically. The single largest lever on both platforms' bills; an unindexed or inefficient query pattern can multiply billed rows well beyond this article's illustrative 10-rows-per-query assumption.
- Required throughput and latency, for PlanetScale specifically. Determines which compute SKU and topology are needed, which is the entire determinant of PlanetScale's cost under its current resource-based model.
- Read/write mix. Shifts cost on D1 and Turso toward whichever platform's write-overage rate and included allowance are least generous; has no direct analogue on PlanetScale's capacity-based pricing.
- Indexed columns on D1 specifically. Each indexed write adds a second billable written row (one for the table, one for the index), a real cost multiplier for heavily-indexed, write-heavy tables.
Budgeting traps
- Pricing PlanetScale using its old, now-deprecated row-read/row-write Scaler rates. That plan no longer exists; current pricing is resource-based (compute SKU, storage, egress), and no published per-row rate applies.
- Assuming a "100 million queries" workload translates into one PlanetScale number the way it does for D1 or Turso. It doesn't; PlanetScale's cost depends on provisioned capacity, and the same query volume could fit a small or require a large SKU depending on query complexity and latency requirements.
- Assuming D1's per-million-row read rate alone predicts total cost. At this workload, D1's write-row charge and storage charge both exceed its read charge (which is $0), making reads the least important line item despite being the largest raw row count.
- Forgetting D1 bills Workers compute separately from its own row-based charges. The database query cost and the compute cost of running the Worker that issues the query are two different line items.
What to ask before you buy
Ask PlanetScale directly for a sized SKU recommendation based on your actual query complexity, concurrency, and latency requirements, since its current Base plan pricing has no published formula connecting query or row volume to cost the way D1's and Turso's do. Measure your application's actual rows-touched-per-query ratio on a representative query sample before comparing D1 and Turso specifically, since that ratio — not raw query count — is what both platforms' billing models actually respond to.