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. In 2025 the bet is paying off — for the right workloads.
Our verdict
Best for: Read-heavy apps with global users, embedded multi-tenant systems where every customer gets their own DB, lightweight serverless workloads on Cloudflare Workers or Vercel.
Not for: Complex relational analytics, high-write workloads with strong consistency requirements across regions, teams that want a managed Postgres without learning a new dialect.
Turso made a counterintuitive bet in 2023: SQLite — not Postgres — was the right model for the next generation of internet apps. The pitch was a managed libSQL (their open-source SQLite fork) with edge replication, embedded clients, and per-database isolation. Eighteen months in, the bet has matured into a real product. After two side projects on Turso through Q1 2025, here’s the working take.
What Turso actually is
Three things in one wrapper:
- libSQL — a fork of SQLite that adds replication, an HTTP API, and incremental snapshots. Open source. You can run it yourself.
- Turso (the managed service) — hosted libSQL with global replication, an SDK for each major language/runtime, and a free tier that is real.
- Embedded replicas — a client-side libSQL instance synced from the cloud. Your app reads locally; writes go to the primary; replicas update in the background.
The third piece is the secret weapon. For read-heavy apps, embedded replicas turn every read into a local-disk SQLite query — submillisecond, no network. Writes still cost a round-trip but are usually rare.
Where it shines
Multi-tenant SaaS with per-customer databases
Turso’s killer use case. Most managed Postgres providers charge per database (or get expensive fast as databases multiply). Turso prices on storage + requests, not per-database, so spinning up 10,000 customer-isolated databases is cheap and operationally trivial.
The per-tenant isolation also solves a category of security problems: a tenant can never query another tenant’s data because they literally have different files.
Cloudflare Workers / Vercel Edge / serverless
If you ship on edge compute, Turso is the easiest database option. The client is a fetch-compatible HTTP API — no connection pooling, no cold-start penalty for opening a TCP socket. It works inside Workers in 50ms, Vercel Edge in 80ms, AWS Lambda in 100ms.
The alternative for edge work is Neon’s HTTP proxy or Cloudflare D1 — both serviceable, but Turso is the most mature.
Embedded for local-first / offline-first apps
If you’re building Linear-style or Notion-style local-first apps, Turso’s embedded replicas mean your client app reads from a local SQLite database with eventual sync to the cloud. This is a hard architecture to build yourself; Turso ships it.
Where it doesn’t fit
Pros
- Per-tenant database isolation at multi-tenant SaaS scale
- Read latency is local-disk fast via embedded replicas
- Free tier is genuinely usable for side projects
- Open-source libSQL — no permanent vendor lock-in
- Excellent fit for Cloudflare Workers, Vercel Edge, and similar edge compute
- Cost scales sensibly with storage, not per-database
Cons
- SQLite’s relational model has limits — no native JSON path ops as ergonomic as Postgres’s, weaker concurrent-write story
- Strong consistency across regions is not the default; embedded replicas are eventually-consistent
- Smaller community than Neon / PlanetScale — fewer tutorials, fewer LLM-trained patterns
- Postgres-trained engineers find some dialect differences annoying
- Backup and PITR are improving but still less mature than the Postgres incumbents
- For complex analytics queries, you’ll wish you had Postgres
The biggest practical limitation: SQLite has one writer at a time per database. Turso’s architecture papers over this for many workloads, but if your app has high concurrent-write contention, you’ll feel it.
What the community is saying
Reddit signal on Turso in early 2025 is quieter than on Neon or Supabase, but consistently positive. The r/Database hosted-databases-speed thread surfaces Turso as a top pick for edge workloads. The criticism that recurs is dialect-related — “I had to rewrite my Postgres triggers” — which is unavoidable if you switch DB engines and not really a Turso problem.
The YouTube tech-edu community (Theo, Web Dev Simplified, Fireship-adjacent) treats Turso as a serious option but not a flagship recommendation. The pattern: serious devs use it for the workloads it’s good at, default-recommend Neon for general Postgres needs.
Pricing in April 2025
- Hobby: free. 500 databases, 9GB total storage, 1B row reads, 25M row writes per month. Real free tier.
- Scaler: $29/month. 10k databases, 24GB, more requests.
- Pro / Enterprise: usage-based above that.
Hobby is enough to run a small SaaS for free. Scaler is enough for most growth-stage apps.
The recommendation
Use Turso if you’re shipping on edge compute, building a multi-tenant SaaS with per-tenant isolation, or want local-first architecture without rolling your own sync. Don’t use Turso as your default “I need a database” pick — Neon or Supabase Postgres remain better defaults for generic web app workloads.
For TopInsight’s own stack, we’re using Cloudflare D1 (which has caught up enough to handle our content metadata) but Turso is on the consideration set for the future pipeline state store. The bet on libSQL has matured enough that it’s no longer a risk to take — it’s a tool to know about.
Sources
Every reference behind this piece. If we make a claim, it's because at least one of these said so — or we lived it ourselves.
- Firsthand Shipped two side projects on Turso during late 2024 / early 2025
- Docs Turso documentation — Turso
- Changelog libSQL changelog on GitHub — Turso
- Blog r/Database — hosted databases speed thread — r/Database
- YouTube Theo and Web Dev Simplified on Turso/libSQL — Various