Pricing
Camille Forster12 min read545 views

Turso Pricing in 2026: The Rows-Read Bill Explained

Turso's 2026 pricing turns on one meter most guides skip: rows read. Here is the real 30-day bill, the index that cuts it, and when Scaler beats Pro.

Updated on October 6, 2026

Deep green editorial illustration of a monthly database invoice with an oversized usage meter pinned near its maximum
Deep green editorial illustration of a monthly database invoice with an oversized usage meter pinned near its maximum
On this page

Quick answer: Turso's 2026 pricing looks simple, four plans from a $0 Free tier to a $499/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 85%, and the surprising point (around 7.25 trillion rows a month) where Pro finally beats Scaler. Monthly prices verified against Turso's pricing page, September 5, 2026, and re-verified against it on October 6, 2026 with every plan price, included allowance and overage rate below unchanged.

Correction, September 5, 2026: this teardown first published the plan prices as $4.99 Developer, $24.92 Scaler and $416.58 Pro and described them as monthly. Those are Turso's annual-billed rates expressed as a monthly equivalent, which is what its pricing page shows in its default state. The month-to-month prices are $5.99, $29 and $499, taken from the structured pricing data Turso publishes on its pricing page. Every worked bill, the crossover point and the Math check below have been recalculated on the monthly rates. If you prepay for a year the older figures still apply.

Correction, October 6, 2026: three further fixes. First, this teardown presented overage billing as automatic. It is not: Turso disables overages by default, and with them off, exceeding any single allowance blocks your databases rather than enlarging your invoice. A new section below sets out what that means for the two overage bills. Second, the index section described CREATE INDEX as a cost-free win; Turso publishes two counter-costs, a one-off full table scan to build the index and a standing increase in rows written, both now stated. Third, two figures were left behind by the September 5 recalculation and were still computed on the old annual-billed rates: the heading on the index section said 86% where the monthly rates give 84.7%, and the Pro-versus-Scaler section said Scaler stays cheaper until "nearly 6 trillion" rows a month where the monthly rates put the crossover at 7.25 trillion, the figure the same section already quoted two sentences earlier. Both are corrected below.

What are Turso's 2026 plans?

Turso logo 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 (re-verified October 6, 2026):

Scroll to see more

PlanMonthly priceRows read includedRows written includedStorageDatabases
Free$0500M10M5 GB100
Developer$5.992.5B25M9 GBUnlimited
Scaler$29100B100M24 GBUnlimited
Pro$499250B250M50 GBUnlimited

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.

There is a fourth metered resource, Embedded Syncs, measured in GB of pages moved between Turso Cloud and a local embedded database (24 GB included on Scaler, then $0.25 per GB). It only bills if you run embedded replicas that sync; a purely server-side app never touches it. It matters here for one reason, covered below: the blocking rule counts it alongside the other three.

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 published monthly rates, re-verified October 6, 2026. Rounding is deliberate; the point is the shape of the bill, not the last cent.

Small SaaS on Developer: $5.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: $5.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: $189, then $29

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 $29, storage and writes inside caps

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

Read-heavy analytics on Scaler: $357

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 $29

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

Those bills only happen if you switch overages on

Both overage bills above assume a setting that is off when you start. Turso's pricing page states it plainly: "Overages are disabled by default. Enable them to go over your plan's included limits and pay per usage at the rates above" (Turso pricing, October 6, 2026). You turn it on in the dashboard or with turso plan overages enable.

With overages off, passing an allowance does not produce a bigger invoice. It produces an outage. From Turso's own pricing FAQ: "Once you exceed the limit on any single metric (storage, rows read, rows written, or syncs), your databases are blocked, even if the other metrics are still well under quota." The billing documentation gives the failure an error code, BLOCKED (Turso usage and billing, 2026).

Two consequences worth planning for. First, the block is account-wide across all four meters, not scoped to the one you overran, so the $189 app above has tiny storage and trivial writes and would still stop serving reads if either ran out. Second, $189 and $357 are what that traffic costs having opted in. The default outcome for the identical month is a $29 invoice and a database that stopped answering. Pick which failure you would rather explain before the month that tests it.

Turso also publishes a one-shot escape hatch aimed squarely at the scenario this teardown is about. Its "Vegas Blackout" lets you nominate any single day each month, before the invoice closes, and strike that day's reads, writes, storage and syncs from the bill, for "the day a runaway query, bot swarm, or other bad day blew up your numbers." It forgives one bad day, not a bad quarter: the usage itself is not erased, and you still need overages enabled to keep serving past the limit.

The one index that cuts a Turso bill by 85%

Go back to the $189 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 $189 to $29. That is an 84.7% 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 usually the cheapest line item you will ever remove.

Usually, not always, and Turso publishes both counter-costs. Building the index is itself billable: "Adding an index to an existing table triggers a full table scan, with one read per existing row" (Turso usage and billing, 2026). On this 50,000-row table that is a one-off 50,000 rows read, around four ten-thousandths of one percent of the 12-billion-row month above, so it does not move this bill at all. The standing cost is the one to weigh: Turso's pricing FAQ states that "a single INSERT, UPDATE, or DELETE on a table with indexes counts as more than one row written, because each affected index also has to be updated," and that "adding more indexes makes writes count more." Rows written bill at $0.80 per million on Scaler, so every index on a hot write path carries a permanent price. Here that trade is not close, because the app barely writes. On a table you write to constantly, do the arithmetic before you add the fourth index.

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 $499 a month versus Scaler's $29. 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: $29 + (R minus 100) times $0.80
  • Pro: $499 + (R minus 250) times $0.75

Solve, and the crossover lands at about R = 7,250 billion, or roughly 7.25 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 $749 and Pro about $1,062.

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 roughly 7.25 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 logo 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 logo 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 logo 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 ($5.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 monthly rates, one CREATE INDEX turned a 300-billion-rows-read month into a 12-billion one and cut the bill from $189 to $29, an 84.7% reduction, while Pro does not beat Scaler on read cost until roughly 7.25 trillion rows a month. Both overage bills assume you enabled overages; with them off the same month ends at $29 and a blocked database.

Sources

C

Written by

Camille Forster

Camille Forster writes BudgetForge's pricing teardowns, turning confusing vendor meters into the real monthly bill you actually pay.

Frequently asked questions

Is Turso free?

Yes. Turso's Free tier is $0 a month and includes 500 million rows read, 10 million rows written, 5 GB of storage, and up to 100 databases (re-verified October 6, 2026). That covers most hobby and early-stage apps as long as your queries are indexed.

What is a "row read" in Turso pricing?

A row read is any row the database engine touches while resolving a query, not the number of rows returned. A primary-key or indexed lookup reads a handful of rows; a query with no usable index does a full table scan and reads every row in the table, even if it returns one.

Why is my Turso bill so high?

Almost always because a hot query has no usable index and scans an entire table on every request. Rows read is Turso's dominant meter, so one unindexed endpoint hitting a 50,000-row table across millions of requests can generate hundreds of billions of rows read. Run EXPLAIN QUERY PLAN and look for SCAN instead of SEARCH.

How much does Turso cost at scale?

The Scaler plan is $29 a month and includes 100 billion rows read; beyond that you pay $0.80 per billion rows read, $0.80 per million rows written, and $0.50 per GB of storage (re-verified October 6, 2026). A read-heavy app reading 500 billion rows a month lands around $357.

Does adding an index lower my Turso bill?

Usually, and in our worked example dramatically: one CREATE INDEX cut rows read from 300 billion to 12 billion and dropped the monthly bill from $189 to $29, an 84.7% reduction, because the query planner replaces a full table scan with a b-tree seek. It is not free, though, and Turso publishes both costs. Building the index triggers a full table scan at one row read per existing row, a one-off charge. Afterwards every INSERT, UPDATE or DELETE on that table counts as more than one row written, because each index has to be updated too, and rows written bill at $0.80 per million on Scaler. On a read-heavy table the trade is overwhelming. On a write-heavy one, do the arithmetic first.

When should I upgrade from Turso Scaler to Pro?

Upgrade for storage headroom (50 GB versus 24 GB), the SLA, and support, not to save money on reads. On read overage alone, Scaler plus overage stays cheaper than Pro's $499 base until roughly 7.25 trillion rows read a month. If you are reading that much, add an index first.

How does Turso pricing compare to Neon and Cloudflare D1?

Turso and Cloudflare D1 both meter rows read and written, so indexing discipline controls the bill. Neon instead prices on compute-hours plus storage, so you pay for how long Postgres is awake rather than rows touched. Match the meter to your query shape: read-heavy indexed workloads suit a rows-read meter, compute-spiky ones may suit Neon.

Build vs buy

Build vs buy: when DIY beats SaaS at scale

Build-vs-buy isn't a values debate, it's a breakeven date. SaaS wins early because it converts a big upfront build into a small monthly fee. DIY wins once your usage-based SaaS bill exceeds the fully-loaded cost of owning the code, typically around month 18 for infrastructure-style tools. This piece gives you the formula, a worked example, and the three traps that make teams build too early.

6 min read564