Turso review — edge SQLite has matured into a real production option

Turso bet a year and a half ago that libSQL + edge replication would beat managed Postgres for read-heavy apps with globally-distributed users. In 2025 the bet is paying off — for the right workloads. This is the working review from shipping two side projects on Turso during late 2024 / early 2025.

The April 2025 context matters: edge SQLite was no longer a curiosity by then. [Cloudflare D1”s parallel push toward read replicas (eventually shipping August 2025, covered in our D1 read replicas analysis)](/databases/d1-read-replicas-launch/) shows the broader pattern — multiple credible vendors competing in the edge-SQL space. Turso”s position: the most mature SQLite-specific edge offering, with the libSQL fork providing the technical foundation.

What Turso actually is

Turso is a managed libSQL service. libSQL is a fork of SQLite with extensions for distributed operation (replication, multi-tenancy, async writes). Turso runs libSQL globally; you create databases per-app, per-tenant, or per-region depending on your pattern.

The pitch:

• Edge-distributed SQLite reads. Queries hit the nearest replica with low latency
• Per-customer databases. Multi-tenant pattern where each tenant gets a dedicated database (no noisy-neighbor problems)
• Embedded option — libSQL can run in your application alongside the remote database
• Generous free tier: 9GB storage, 1B row reads/month on Hobby
• Simple pricing at higher tiers ($29/mo Scaler)
• SQLite compatibility — most SQLite tools work; familiar dialect

What Turso actually wins at

After shipping two side projects on it:

1. Read-heavy apps with global users. This is the canonical Turso use case. Page loads, API responses, content delivery — all latency-sensitive read operations benefit dramatically from edge replication.

2. Multi-tenant SaaS with strict isolation. Per-customer databases work in Turso in a way that”s painful in Postgres. Each customer”s data is in a separate SQLite file; no shared-table noisy-neighbor concerns; per-tenant backup / export becomes trivial.

3. Embedded patterns. Run libSQL in your app process for reads (local replica), sync writes to Turso. For specific workloads (offline-first apps, low-latency dashboards), this is dramatically faster than network roundtrips.

4. Lightweight serverless workloads. Cloudflare Workers, Vercel Edge Functions, Deno Deploy — anywhere cold-start matters and the working set is small.

What Turso doesn”t do well

1. Complex relational analytics. SQLite”s query planner isn”t Postgres-grade. Complex joins, window functions, recursive CTEs work but may underperform.

2. High-write workloads with strict consistency. libSQL”s write path goes through the primary; replication is eventually consistent. If your app writes heavily and needs “read your own writes” everywhere, the architecture friction is real.

3. Workflows requiring Postgres-specific features. pgvector, hstore, json operators, advanced full-text search — SQLite has analogs for some but not all.

4. Teams accustomed to Postgres”s observability tools. Postgres has 20+ years of monitoring tooling, EXPLAIN ANALYZE depth, query optimization expertise in the community. SQLite”s equivalent is thinner.

The AI Jason “reduced 90% errors” connection

AI Jason”s April 8 video — “How I reduced 90% errors for my Cursor” — and his April 22 Part 2 cover the broader workflow discipline that pays off for any tech-stack choice. The database decision matters less than the application-architecture discipline around it.

The connection to Turso: SQLite”s simplicity rewards careful schema design. Without joins-spanning-many-tables crutches, you”re forced to think about data access patterns upfront. For teams that do this well, SQLite + Turso is liberating. For teams that don”t, the missing Postgres features bite later.

The Theo “switched to Postgres” counter-narrative

Theo”s July 4 video — “I finally switched to Postgres” (published 3 months after this article) — captured the broader “consolidate to boring infrastructure” sentiment that 2025 saw across the industry. The implicit argument: SQLite (and Turso) are interesting but Postgres is the safer default for most apps.

The honest read: both can be right depending on your workload.

• For read-heavy, globally-distributed, multi-tenant apps: Turso/D1/SQLite-edge wins
• For traditional OLTP, complex queries, established Postgres expertise: Postgres wins
• For the gray middle: Postgres usually wins because the ecosystem is deeper

Turso”s niche is real but narrow. Within the niche, it”s the best option.

The Cloudflare D1 competition

The r/CloudFlare “Cloudflare Containers” launch thread (155 upvotes, June 24) and Cloudflare”s broader 2025 product expansion shifted the edge-database landscape. D1”s August 2025 read-replicas release (after this article) brought Cloudflare”s native option to feature parity with Turso for many use cases.

The differentiator going forward:

• Turso wins on the embedded-libSQL pattern, multi-tenant per-customer databases, and SQLite-specific extensions
• D1 wins if you”re already on Cloudflare Workers and want platform consolidation
• Both are credible for the read-heavy global-user use case

The r/CloudFlare June 12 outage thread (674 upvotes) captures the broader edge-platform reliability question. Multi-provider hedging matters for primary data, regardless of which edge SQL provider you pick. Both Turso and D1 are good; relying entirely on one is the risk.

The SQL tooling adjacent context

The r/golang “Bob can now replace both GORM and Sqlc” thread (211 upvotes, May 26) — slightly post this article — captures the broader 2025 SQL tooling evolution. The ecosystem around SQL (ORMs, query builders, type-safe DB access) has matured significantly through 2024-2025, which makes SQLite-based options more practical for serious work.

For Turso specifically: Drizzle ORM, Kysely, libsql client libraries — the TypeScript ecosystem is now solid. Go has its own thriving ecosystem (Bob, sqlc, GORM all work with libSQL). The “SQLite means hand-writing SQL” stigma is mostly obsolete.

Production patterns that work

Three patterns that emerged from real Turso use:

1. Single primary database with edge reads. Simple. Default Turso setup. Works for most apps.

2. Per-tenant databases for SaaS. One Turso database per customer. Excellent isolation; trivial export / backup per tenant; works with libSQL”s multi-tenancy primitives.

3. Embedded libSQL with Turso sync. Run a local libSQL replica in your app process; query it for reads (microsecond latency); writes go to Turso primary with async sync. Great for offline-first apps, low-latency dashboards.

Creator POV vs Reddit dissent

The creator landscape doesn”t cover Turso intensively. Edge SQLite is a niche topic that doesn”t generate video content the way model launches or framework wars do. Turso”s mindshare is mostly developer-blog and Twitter; YouTube coverage is thinner.

The Reddit dissent through 2025 splits productively:

The pro-Turso camp — for users who tried it and stuck with it. Values: per-tenant DB simplicity, edge latency, generous free tier.

The “just use Postgres” camp — pragmatic majority. SQLite (and Turso) requires unlearning Postgres assumptions; for many apps the gain doesn”t justify the friction.

The “D1 ate Turso”s lunch” camp — gaining momentum after D1 read replicas. For Cloudflare-deployed apps, why use Turso when D1 is native?

The “Turso is real but narrower than they claim” camp — accurate. Marketing positions it as Postgres replacement; reality is “Postgres replacement for specific workloads.”

What this means for working engineers in mid-April 2025

Three practical positions:

1. If you”re building a read-heavy global-user app, evaluate Turso. Free tier is generous; the latency gains are real for the right workload.

2. If you”re building multi-tenant SaaS with strict isolation needs, Turso”s per-customer DB pattern is a real unlock. Postgres can do this but Turso makes it trivial.

3. If you”re building OLTP-heavy or complex-query apps, default to Postgres. Turso is the wrong tool for these patterns.

The honest critique

What this review doesn”t cover:

• D1 catching up. Through 2025, Cloudflare D1 closed many feature gaps. By late 2025, the Turso-vs-D1 choice is more about ecosystem alignment than capability gap.
• Turso”s long-term business model. VC-funded, in a competitive space. The “what happens to Turso in 3 years” question is unresolved.
• Migration off Turso is non-trivial. SQLite-flavored schemas don”t cleanly port to Postgres if you”ve used SQLite-specific patterns. Vendor lock-in risk is real.
• Per-tenant database patterns have operational implications. Backup management, schema migrations, monitoring — all get more complex with many small databases vs one big one.

For most working engineers reading this in mid-April 2025: Turso is a real, useful option for specific workloads — and not the Postgres replacement its marketing implies. For read-heavy, globally-distributed, multi-tenant patterns: it”s excellent. For typical OLTP apps: pick Postgres on a managed provider and don”t look back.

For broader edge-database context, see our Cloudflare D1 read replicas analysis and Neon vs Supabase vs PlanetScale comparison.