Turso row reads: what they cost, and what 1 billion reads a month bills

Turso prices reads the way a phone plan prices minutes: a large included volume, then a per-unit rate, with a hard stop on the free tier. For an app that does a billion reads a month the arithmetic is short, and the interesting part is not the price but what counts as a read.

One billion row reads a month costs $4.99, because Developer's allowance is 2.5 billion and the plan fee is the only charge. Free cannot carry the same app at all: 500 million rows read is the limit, and Turso's documentation says exceeding a quota fails the query, not the invoice.

What a row read costs on each plan

The Free plan also carries 10 million row writes, 5 GB of storage and 100 databases. Developer raises storage to 9 GB at $0.75 per GB beyond, and Scaler to 24 GB at $0.50 per GB beyond.

What the row-read number actually means

A row read is a row scan, and that distinction is where budgets go wrong. Turso's documentation is explicit: the term row read refers to a row scan during statement execution, queries may scan more rows than they return, each updated row results in at least one scan, and aggregates, full table scans, joins and some ALTER TABLE statements scan a row at a time. Even select 1 counts as one row read.

So the unit is closer to "pages examined" than "results delivered". An app that fetches 1,000 rows by primary key is cheap. The same app running a report over 1,000,000 rows without an index reads 1,000,000 rows to return a number, and repeating that report 1,000 times a month is a billion reads on its own.

The allowance structure is unusual in one respect: it is generous by an order of magnitude. Developer includes 2.5 billion reads for $4.99, which is $1.996 per billion at full consumption, and Scaler includes 100 billion for $24.92, which is $0.25 per billion. The overage rates only matter when a plan is nearly exhausted.

How we measured it

The included volumes, overage rates and plan prices are quoted from Turso's pricing page on 2026-10-25; the definition of a row read and the BLOCKED behaviour come from Turso's usage and billing documentation on the same date. Nothing was provisioned and no query was run against a Turso database, so no scan multipliers were measured. The 1 billion-read example is arithmetic against published allowances and is marked calculated.

What changes in practice

The first practical consequence is that a blocked query is worse than a bill. On Free, crossing 500 million reads stops the app rather than charging for the excess, so a read-heavy prototype needs Developer at $4.99 before it ships, not after it fails.

The second is that indexing is a billing decision. Every full table scan is charged per row, which means the same schema change that fixes latency also cuts the bill. A monthly report that scans 2 million rows costs 2 million reads; add the index and it reads thousands.

The third is the crossover between the two paid tiers. Developer's $1 per billion sounds cheap until volume passes 22.4 billion reads, where $4.99 plus overage exceeds Scaler's $24.92 — and Scaler also drops the rate to $0.80 per billion with far more headroom.

The fourth is write amplification on the same meter. Turso counts each updated row as at least one row read and one row write, so a nightly job that updates 1 million rows consumes 1 million of each and returns nothing — 30 million writes a month against Developer's 25 million allowance.

Bottom line

For an app reading 1 billion rows a month, Developer at $4.99 is the whole bill and the cheapest tier that will not block. Budget Scaler's $24.92 from roughly 22 billion reads upward, and treat row scans — not row counts returned — as the number to put on a dashboard before traffic arrives.