Turso Pricing in 2026: The Rows-Read Bill Explained

Quick answer: Turso's 2026 pricing looks simple, four plans from a $0 Free tier to a $416.58/mo Pro tier, but the number that actually moves your bill is rows read. Turso meters every row your queries touch, and one unindexed query can read an entire table on every request. Below is the real 30-day math: how the meter works, three worked bills, the single index that cut a mid-size bill by 86%, and the surprising point (around 5.7 trillion rows a month) where Pro finally beats Scaler. Prices verified against Turso's pricing page, July 2026.

What are Turso's 2026 plans?

Turso is a hosted database built on libSQL, a fork of SQLite, sold on four plans. Here is what each includes, from Turso's pricing page (July 2026):

Overage rates matter more than the sticker, because most real apps blow through one allowance long before the others. On Scaler you pay $0.80 per billion rows read, $0.80 per million rows written, and $0.50 per GB of storage over the cap. On Developer it is $1 per billion rows read and $1 per million written. On Pro the read rate drops to $0.75 per billion.

Notice the asymmetry. A million written rows and a billion read rows cost the same $0.80 on Scaler. Turso expects you to read far more than you write, and it prices accordingly. That single design choice is why rows read, not storage and not writes, is the meter that decides your bill.

What does "rows read" actually count?

This is the part almost no pricing summary explains, and it is where the surprise bills come from.

A row read is not a row returned. It is a row the database engine touches while resolving a query. Turso counts rows read the way SQLite scans them:

• A primary-key lookup (WHERE id = ?) reads roughly 1 row.
• An indexed lookup reads the matching rows plus a few b-tree nodes.
• A query with no usable index does a full table scan: it reads every row in the table, even if it returns one.
• COUNT(*) without a covering index reads every row.
• A join can multiply: rows scanned in the driving table times rows probed per match.

Here is the trap in one line. If a hot query filters a 50,000-row table on a column with no index, every single request reads 50,000 rows. At 2 million requests a day that is 3 trillion rows read a month from one endpoint. Your storage is tiny, your writes are trivial, and your bill is still four figures.

The SQLite query planner documentation (2026) spells out exactly when a query can use an index versus when it falls back to a scan. On Turso, that document is effectively a pricing manual.

Three real 30-day Turso bills

Numbers below use Turso's July 2026 rates. Rounding is deliberate; the point is the shape of the bill, not the last cent.

Small SaaS on Developer: $4.99, all-in

A dashboard app: 500,000 page views a month, every view firing a handful of indexed queries that read about 300 rows total. That is 150M rows read, well under the 2.5B Developer allowance. Writes are 2M a month, storage 3 GB. Nothing goes over.

Bill: $4.99. Small, indexed apps live inside the Developer tier for the price of a coffee. This is Turso at its best.

Mid-size app with one bad query: $184.92, then $24.92

A busier product on Scaler: 2M requests a day. Most queries are indexed, but one hot list view filters a 50,000-row table on an unindexed status column, so it scans the whole table, about 5,000 rows read per request after the query planner gives up on the index.

• 2M requests/day times 30 = 60M requests
• 60M times 5,000 rows = 300B rows read
• Allowance 100B, overage 200B times $0.80 = $160
• Base $24.92, storage and writes inside caps

Bill: $184.92 a month. Rows read are 86% of it. Storage is a rounding error.

Read-heavy analytics on Scaler: $352.92

An app doing edge-side aggregation: 500B rows read a month, 30M writes, 40 GB storage.

• Rows read: (500B minus 100B) times $0.80 = $320
• Storage: (40 minus 24) GB times $0.50 = $8
• Base $24.92

Bill: $352.92 a month. Again the read meter dwarfs everything else.

The one index that cuts a Turso bill by 86%

Go back to the $184.92 app. The fix is not a plan change. It is one line of DDL.

Add an index on the column the hot query filters, and the query planner switches from a full table scan to a b-tree seek. Instead of reading all 50,000 rows, the query reads the handful that match plus a few index nodes, call it 200 rows per request.

• 60M requests times 200 rows = 12B rows read
• 12B is under the 100B Scaler allowance
• Overage: $0

Bill drops from $184.92 to $24.92. That is an 86.5% cut from a single CREATE INDEX, with no upgrade and no code rewrite. On a rows-read meter, indexing is not just a latency win. It is the cheapest line item you will ever remove.

Run EXPLAIN QUERY PLAN on your top ten queries. Every SCAN (as opposed to SEARCH) on a table larger than a few thousand rows is a bill waiting to happen.

When does Pro actually beat Scaler?

Pro costs $416.58 a month versus Scaler's $24.92. It includes more: 250B rows read versus 100B, and cheaper read overage ($0.75 versus $0.80 per billion). So at some read volume Pro wins. The question is where.

Set the two bills equal for read volume R (in billions), ignoring storage:

• Scaler: $24.92 + (R minus 100) times $0.80
• Pro: $416.58 + (R minus 250) times $0.75

Solve, and the crossover lands at about R = 5,683 billion, or roughly 5.7 trillion rows read a month. Below that, Scaler-plus-overage is cheaper than Pro, often by a lot. At 1 trillion rows read, Scaler bills about $744 and Pro about $979.

The practical read: upgrade to Pro for its storage headroom (50 GB versus 24 GB), its SLA, and its support, not to save money on reads. On read economics alone, Scaler stays cheaper until you are reading nearly 6 trillion rows a month, and if you are reading that many rows you almost certainly have an index to add first.

Turso vs Neon vs Cloudflare D1: three meters, three bills

Turso meters rows read and written. That rewards tight indexing and punishes table scans, and it makes reads and writes roughly comparable in cost.

Neon prices on compute-hours plus storage, per Neon's pricing (July 2026). You pay for how long your Postgres compute is awake, not for rows touched, so an unindexed query costs you CPU time and cold-start risk rather than a per-row meter. Our full Neon pricing teardown walks that math.

Cloudflare D1 uses the same rows-read-and-written model as Turso, per Cloudflare's D1 pricing (2026). If you understand Turso's meter, you already understand D1's, and the same indexing discipline applies to both.

The lesson is that the meter, not the sticker price, decides which database is cheap for your workload. A read-heavy app with disciplined indexing is cheapest on a rows-read meter. A write-heavy or compute-spiky app may be cheaper on Neon's compute model. Match the meter to your query shape before you pick on headline price. If you are weighing a managed database against running your own, our build-vs-buy math covers the crossover.

The bottom line

Turso is genuinely cheap for small, well-indexed apps ($4.99 covers a lot) and stays reasonable at scale if you respect the rows-read meter. The failure mode is not the price list. It is a single unindexed query multiplying across millions of requests. Read your query plans before you read your invoice.

Math check: on Turso's 2026 rates, one CREATE INDEX turned a 300-billion-rows-read month into a 12-billion one and cut the bill from $184.92 to $24.92, an 86.5% reduction, while Pro does not beat Scaler on read cost until roughly 5.7 trillion rows a month.