Turso

Turso is distributed SQLite at the edge. The team forked SQLite into libSQL, replicated it across 30-plus regions, and built a database product that gives you single-digit millisecond reads worldwide.

It's a different shape from Postgres or MySQL. Same SQL, very different topology. Worth understanding before you adopt it.

What Turso actually does

Turso runs libSQL servers in regions all over the world. Your primary database lives in one region. Replicas serve reads from the closest region to each user.

The clever twist is database-per-tenant. Spinning up a thousand small databases on Turso costs essentially the same as one big one. That changes how you think about multi-tenancy.

Embedded replicas sync from the cloud to your local app. The app reads from a local SQLite file, syncs in the background, and gets the closest possible read latency: zero.

Who Turso is for

Multi-tenant SaaS apps giving each customer a private database. Edge-rendered apps reading from the user's nearest region. Mobile and offline-first apps with embedded replicas. Read-heavy dashboards on Cloudflare Workers.

It's not the right pick for write-heavy workloads or apps that need strict global consistency. Eventual consistency is the tradeoff.

Turso pricing breakdown

The free Starter tier includes 500 databases, 9 GB total storage, and 1 billion row reads per month. Genuinely generous for hobby or early-stage projects.

Pro runs $29 per month with much higher quotas. Scaler runs $499 per month for production-scale apps with hundreds of millions of operations.

Enterprise tiers are custom-quoted. They add SOC 2, dedicated support, and custom regions.

Per-database overhead is near zero. Spin up a thousand customer databases and your bill barely changes. That's a different pricing shape than Postgres products.

Standout Turso features

Per-region read latency is excellent. Reads come from the closest replica, often single-digit milliseconds. Apps deployed to Cloudflare Workers or Vercel Edge feel instantaneous.

Database-per-tenant at near-zero overhead unlocks new architectural patterns. Each customer gets a private database with no shared schema, no noisy neighbors, full isolation.

Embedded replicas sync to your local app. Mobile apps and desktop apps read from a local SQLite file with cloud sync in the background. Offline support comes for free.

SQLite compatibility means cheap local development. Run Turso locally as a plain SQLite file. Deploy to the cloud when you're ready.

Open-source libSQL server lets you self-host the whole stack. The cloud product is the convenience pick, not the only path.

Honest tradeoffs

Eventual consistency complicates write-heavy workloads. Reads are fast and global. Writes go to the primary region and propagate. If your app writes constantly and expects fresh reads everywhere, you'll fight this model.

SQLite has feature gaps versus Postgres. No PostGIS, no advanced JSON operators, no extensions ecosystem. Most apps don't notice; some apps do.

Tooling is less mature than Postgres. ORMs, dashboards, and migration tools are still catching up. Drizzle, Prisma, and others have decent libSQL support but it's newer.

Turso vs the alternatives

The closest peer is Cloudflare D1. D1 is also SQLite at the edge, also bundled with Workers. Turso has more regions and the embedded-replica model.

PlanetScale and Neon handle different problems. PlanetScale is global MySQL with branching. Neon is serverless Postgres. Both target different use cases than Turso.

Supabase is full Postgres with broader features. Supabase is heavier; Turso is lighter and faster for reads.

For pure offline-first apps, alternatives like RxDB or PowerSync overlap. Turso is the SQL-native answer.

See best edge databases, Turso alternatives, and Turso vs Cloudflare D1.

Bottom line on Turso

Turso fits a specific shape. Read-heavy, multi-tenant, edge-deployed apps benefit immediately. The free tier is generous enough to ship a real MVP.

If your app reads more than it writes and your users span continents, Turso is the smartest pick in the category. The embedded replica trick alone is worth a Saturday of exploration.

Turso for multi-tenant SaaS

The killer use case is database-per-tenant. Each customer gets a private database. No shared schema. No shared data. No noisy-neighbor performance issues. Turso's architecture makes the per-database overhead near zero.

Spinning up a thousand tenant databases costs roughly the same as one big one. That's a fundamentally different cost curve than Postgres or MySQL would offer for the same isolation level.

Customer data deletion becomes trivial. Drop the database. Done. No SQL queries chasing foreign keys. The compliance story for GDPR and similar regulations gets dramatically simpler.

Turso embedded replicas

Embedded replicas sync from the cloud to your local app. The app reads from a local SQLite file. Writes go to the primary; reads come from the local replica. Sync happens in the background.

For mobile apps, this means offline support comes for free. The app keeps working without network. Reads stay fast. Writes queue and sync when connectivity returns.

For desktop and Electron apps, embedded replicas turn the app into something resembling a local-first experience while still backing data up to the cloud.

For server apps, embedded replicas in each server reduce read latency to single-digit milliseconds. Reads never leave the box.

Turso common questions

"Is Turso production-ready?" Yes. Real businesses run on Turso. The libSQL fork is actively maintained.

"Can I use my favorite ORM?" Drizzle has the best support. Prisma works via the libSQL adapter. Some ORMs lag.

"What about consistency?" Reads from replicas are eventually consistent. Reads from the primary are strongly consistent. Choose per query.

"Does Turso support transactions?" Yes within a region. Cross-region transactions don't make sense in this architecture.

Final word on Turso

Turso fits a specific shape and fits it brilliantly. Read-heavy, multi-tenant, edge-deployed apps benefit immediately. The per-database overhead model unlocks new architectural patterns.

If your app reads more than it writes and your users span continents, Turso is the smartest pick in the category. The free tier is generous enough to ship a real MVP.

The embedded replica trick alone is worth a Saturday of exploration. Most developers come away with new ideas about how local-first apps could work.

Turso architecture details

Each Turso database starts in a primary region of your choice. Replicas spin up in additional regions on demand. Reads from the closest replica; writes go to the primary.

The replication is near-real-time for typical workloads. Sub-second propagation is normal. Eventual consistency means recent writes might not appear in remote replicas immediately.

Database creation is fast. Spinning up a new database takes seconds, not minutes. That speed enables database-per-tenant architectures that would be impractical on Postgres.

libSQL is the open-source fork of SQLite that Turso runs. The protocol extends standard SQLite with HTTP and WebSocket support, plus some additional features like remote sync.

Turso for offline-first apps

Embedded replicas in mobile apps mean the app works offline. The local SQLite file holds all the data. Reads happen locally. Writes queue for sync when network returns.

Conflict resolution is application-level. Turso syncs the data; your code decides how to merge concurrent writes. Most apps handle this with last-write-wins or version vectors.

Battery and performance benefits are real. Reading from a local file instead of round-tripping to a server saves milliseconds and milliwatts on every query.

The pattern fits note-taking apps, productivity tools, and field-service apps where users work without reliable connectivity.

Turso for serverless backends

Cloudflare Workers with Turso embedded replicas read from the same network as the function execution. No connection pooling concerns. No cold-start database connection delays.

Vercel Edge Functions and Deno Deploy similarly benefit. The libSQL HTTP driver works in any serverless runtime.

Lambda and other regional serverless platforms work too, with Turso replicas in the same region.

Turso community and ecosystem

Drizzle ORM has the strongest libSQL support. Schema definitions, migrations, and queries all work cleanly.

Prisma supports libSQL via the adapter. Some advanced features lag the Postgres support.

Direct SQL via libSQL clients is the simplest path. Raw queries plus parameter binding cover most use cases.

The community is smaller than Postgres but growing fast. Documentation, tutorials, and example projects multiply quarterly.

Turso long-term outlook

The edge database category is still young. Cloudflare D1, Turso, and a handful of others compete for early adopters.

Turso's bet on libSQL and embedded replicas is distinctive. The patterns it enables (database-per-tenant at zero overhead, offline-first apps with automatic sync) are genuinely new.

Cloudflare D1 is the closest competitor. Bundled with Cloudflare's ecosystem. Slightly different feature set.

For teams who fit the use case (read-heavy, multi-tenant, edge-deployed), Turso is currently the strongest pick. The community is small but growing. Documentation has improved significantly.

The bet on SQLite at the edge could go either way. If the architecture proves correct, Turso becomes a major player. If write-heavy patterns dominate, Postgres products win. Time will tell.