Turso
SQLite at the edge, libSQL fork with replication to 30+ regions, embedded-replicas pattern.
VISIT TURSOKey takeaway: For read-dominant applications rendered at the edge, Turso is the cleanest answer available: SQLite replicated close to your users, with reads that can run in-process rather than over a network. It becomes the wrong tool the moment writes are the hot path. Cloudflare D1 is the better pick if you have already committed to Workers.
Quick facts
- CategorySQLite at edge
- EngineSQLite
- PricingFreemium
- LicenseMIT (libSQL is MIT)
- Created2022
- GitHub stars13.5k
- PostgresNo
- Edge-readyYes
Bundled features: Multi-region replication
What it is
Turso is SQLite at the edge, libSQL (a SQLite fork) replicated to 30+ regions globally with the embedded-replicas pattern (read locally, write through). Generous free tier, pay-per-row pricing. Used heavily for edge-rendered apps where read latency matters more than write strength.
Best for
- Edge-rendered apps where reads dominate writes
- Multi-region apps that want low-latency reads everywhere
- JAMstack-flavoured workloads with database-as-config patterns
When not to pick it
Skip Turso for write-heavy workloads, the embedded-replicas pattern is read-optimised. Skip for apps that need transactional guarantees across regions.
My take
Turso is the cleanest answer for edge-rendered SQLite. The embedded-replicas pattern is the right abstraction for read-dominant apps. Pricing model is the trade-off; pay-per-row gets surprising at scale.
Embedded replicas change where the query runs
The interesting part of Turso is not that it is SQLite in the cloud, it is the embedded-replicas pattern. Your application keeps a local copy of the database as a file in its own process, reads hit that file directly, and writes go to the primary and replicate back. That removes the network from the read path entirely, so a query that would have cost a network round trip becomes a local disk read. For an edge-rendered page doing a handful of lookups per request, the difference is not marginal. The catch is the asymmetry you are buying into. Writes still cross the network to a single primary, and a replica can be briefly behind, so read-your-writes needs explicit handling rather than assumption. Design for it and the model is excellent. Ignore it and you will ship a form that appears not to have saved.
Pay-per-row pricing makes a missing index a billing event
libSQL is MIT licensed and the server is self-hostable, which is a genuinely open exit compared with most of this category. The hosted service prices largely on rows read and written, and that has a consequence worth internalising: an unindexed query that scans a table is no longer merely slow, it is expensive, and it stays expensive on every single request. Teams used to per-hour compute pricing find this surprising, because the cost of a bad query plan is normally paid in latency you can watch rather than in an invoice you read next month. Audit your indexes before launch and watch row counts the way you watch response times. The other limit is write-heavy work: the single-primary model and the replication lag that comes with it mean you should be looking at Postgres, not SQLite at the edge.
Frequently asked questions
Is Turso just SQLite?
It is libSQL, a SQLite fork, so the SQL dialect and file format are familiar and local development can be a plain SQLite file. What Turso adds is multi-region replication and the embedded-replicas pattern, where your app reads from a local copy and writes through to a primary. libSQL is MIT licensed and self-hostable if you want it.
Turso or Cloudflare D1?
D1 if you are building on Cloudflare Workers, because the runtime integration is most of the value and it is cheap at scale. Turso if you want SQLite at the edge without committing to one platform, need replicas in more places, or want the embedded-replicas read path. Turso is the portable choice; D1 is the integrated one.
Can Turso handle write-heavy applications?
Not well, and that is a design choice rather than a defect. Writes go to a single primary and replicate outward, so the architecture optimises reads at the cost of write throughput and immediate cross-region consistency. If writes dominate or you need transactional guarantees spanning regions, use Postgres. Neon or Supabase are the sensible alternatives here.
Links
Compare Turso side-by-side
Similar tools you should also consider
If Turso is your pick, the next conversation is short
The 30-min call is where your database choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders. Describe your stack, your scale, your data shape. I tell you whether Turso is genuinely your fit.