Understand and avoid Turso quota errors: row reads, row writes, storage and the BLOCKED error

Documented steps

1. Know the accounting model: a 'row read' is a row SCANNED, not a row returned; a 'row written' is any insert or update (https://docs.turso.tech/help/usage-and-billing).
2. Check plan allowances against expected load (https://turso.tech/pricing): Free 500M reads / 10M writes / 5GB storage / 3GB sync; Developer 2.5B / 25M / 9GB / 10GB; Scaler 100B / 100M / 24GB / 24GB.
3. Instrument early: monitor usage in the dashboard or via the organization usage endpoints before you approach the ceiling.
4. Index the columns used in WHERE and JOIN predicates — an unindexed filter scans the table and bills every row scanned.
5. Avoid SELECT * over wide tables in hot paths and paginate with keyset pagination rather than large OFFSET scans (OFFSET still scans skipped rows).
6. Batch inserts instead of issuing per-row round trips, and avoid write-amplifying patterns like update-every-row heartbeats.
7. Handle the BLOCKED error code explicitly in your client: it means the quota is exhausted and queries are failing, and it needs an operator alert, not a blind retry loop.