How does Turso pricing work?

Turso plan breakdown and base costs

Turso's pricing model is built on top of SQLite, separating base subscription fees from usage. Point-in-time restore and database branching do not add usage cost on any plan, and idle databases in Turso only incur storage costs. If you run a large fleet of databases that sit idle most of the day, you only pay for the 4KB pages they occupy on disk.

Paid plans bill on the first day of each month. Turso offers five plan tiers: Free, Developer, Scaler, Pro, and Enterprise.

Support and data retention also step up with each tier. The Free plan includes 1 day of Point-In-Time Restore and Community support. The Developer plan gives you Audit Logs with 3 Day Retention, 10 days of Point-In-Time Restore, and Community support.

On Scaler, you get Audit Logs with 14 Day Retention, 30 days of Point-In-Time Restore, and Community support. The Pro plan includes Audit Logs with 30 Day Retention, 90 days of Point-In-Time Restore, and Priority Email support. Enterprise keeps the 30-day audit retention and 90-day restore window, but upgrades your ticket routing to 24x7 Priority Email support.

What counts as a row read in Turso?

In Turso's SQLite implementation, a row read does not mean a row returned to your application. A row read refers to a row scan performed during statement execution.

If your query inspects a thousand rows to find the two records you asked for, you're charged for scanning a thousand rows. This distinction matters because unindexed lookups quietly chew through your monthly read quota. Queries lacking index support perform a full table scan, which incurs one row scan (read) for every row in the table.

EXPLAIN QUERY PLAN
SELECT * FROM users WHERE email = 'alex@example.com';

Developers can use the EXPLAIN QUERY PLAN statement in Turso to check whether a query performs a full table scan or uses an index. If you don't see an index lookup in the plan, SQLite is stepping through the entire table page by page. Adding an index to an existing table fixes future lookups, but creating that index triggers a full table scan itself, incurring one row read for every existing row in the table.

Several other common SQL patterns run up row read totals:

• Using aggregate functions such as count, avg, min, max, and sum causes a row scan for every row considered in the aggregation.
• Table joins, subqueries, and compound queries incur a row scan for each considered row across all involved tables.
• Each updated row in an SQL update statement results in at least one row scan.
• Commands that do not involve reading or writing table rows, such as select 1, default to counting as one row read.

Queries against internal SQLite system tables do not incur row reads. This includes the dbstat virtual table and any tables prefixed with sqlite_.

How Turso counts row writes and total storage

In Turso, a row written encompasses both inserting a new row and updating an existing row. Every write operation hits your ledger, but writes often carry hidden read costs alongside them.

SQL updates read and write each row they modify. Absent an index for row filtering, the update statement performs a full table scan - adding one read for each row in the table - plus one write for each updated row. That means a single sloppy UPDATE statement running on a large table can burn millions of row reads while writing only a dozen lines.

Even failed operations accumulate write usage. Any row inserted or updated during a transaction counts as a row write even if the transaction is aborted and not committed. If your application attempts a batch insert of 50,000 records inside a transaction that fails on the last item, you are still billed for 50,000 row writes.

Schema changes can also produce significant write volume:

• ALTER TABLE operations that rewrite row contents require a full table scan, incurring one row read per table row.
• ALTER TABLE operations can incur one row write for each existing row if the row data is altered during the operation.
• Some structural adjustments, like DROP COLUMN, do not cause full scans.

For disk footprint, Turso calculates total storage across all tables and indexes using the SQLite dbstat virtual table. The base unit for this measurement is a database file page, which is 4KB.

Can you shrink that footprint when you delete data? Not right now. The SQLite VACUUM command for compacting databases and optimizing storage is currently disabled in Turso. If you delete half your rows, those 4KB pages remain allocated inside the database file, so your storage usage stays at the previous high-water mark.

What happens when you exceed Turso quotas

Turso usage limits are measured monthly during each calendar month based on the number of table rows read, number of table rows written, and total storage.

What happens when you hit a ceiling depends on whether you have enabled overages. In billing plans that include monthly quotas for row reads, row writes, and total storage, any query that exceeds these limits will result in a failure, indicated by the BLOCKED error code. Once your database is blocked, normal query execution halts until the start of the next calendar month or until you upgrade your plan.

If you are on a paid plan, extra storage, reads, writes, and syncs beyond your plan's allowance are billed automatically once enabled. The per-unit rates drop as you move to higher tiers:

• Developer overages: +$0.75 per GB of storage, +$1 per Billion rows read, +$1 per Million rows written, +$0.35 per GB of syncs.
• Scaler overages: +$0.50 per GB of storage, +$0.80 per Billion rows read, +$0.80 per Million rows written, +$0.25 per GB of syncs.
• Pro overages: +$0.45 per GB of storage, +$0.75 per Billion rows read, +$0.75 per Million rows written, +$0.15 per GB of syncs.

Because overages bill automatically once turned on, a rogue background worker or a recursive join can push your month-end invoice well past the base plan cost.

Managing Turso spend and overages with Costbrake

When overages are turned off, Turso protects you by throwing BLOCKED errors at the quota limit, which leaves your spend capped at the base subscription fee. Once you turn overages on to preserve uptime, your bill becomes variable.

Costbrake watches what you spend across 23 cloud, AI, and SaaS providers, including Turso, Neon, and Cloudflare. It monitors organization usage and alerts you when your consumption trends toward a budget overrun:

• Hourly checks run on the Free plan and 5-minute checks run on Pro and Team.
• A spike alert triggers when an hour costs more than 3x the usual hour based on your 7-day baseline and adds at least $5 more than usual.
• Budget alerts trigger at 50%, 80%, and 100% of your limit, alongside month-end forecasts based on the pace of the last 72 hours.
• Brakes let an admin step in manually with a click and confirmation. For Turso, Costbrake provides two reversible brakes: you can block writes to make a database read-only while reads keep working, or you can block reads and writes to halt all queries on a runaway database without deleting its data.

You can learn more on the Costbrake pricing page or set up tracking in a few minutes via agent setup.