Turso made a real bet: SQLite (via their libSQL fork, and more recently a ground-up rewrite of the database itself) served over the network, replicated close to users, cheap enough that you can hand every tenant their own database. For read-heavy apps with global users, that bet pays off — queries hit a replica milliseconds away, and the database-per-tenant pattern that's painful on Postgres becomes almost free.
But SQLite-over-the-network is a specific shape, and after a while some teams find it's not their shape. The reasons people go looking for Turso alternatives cluster into a few buckets:
- Write concurrency. SQLite is fundamentally single-writer. Turso engineers around this well, but if your workload is write-heavy and contended, you're fighting the storage engine.
- You miss the big-database toolbox. Postgres extensions, rich types, stored procedures, mature ORMs and BI tools that assume a "real" server database.
- The network driver isn't local SQLite. SQLite's magic is embedded, zero-latency reads. Once queries go over HTTP or a driver protocol, you're managing latency like any other remote DB — embedded replicas mitigate this, but they're another moving part.
- Platform bets. Turso is a young company that has already made one major architectural pivot. Some teams love that velocity; others want boring.
Depending on which bucket you're in, the right alternative is very different. Here are the six worth considering, honestly assessed.
1. Cloudflare D1 — if you're staying in the edge-SQLite lane
[D1](https://developers.cloudflare.com/d1/) is Cloudflare's managed SQLite, and it's the most direct substitute: same storage engine philosophy, same edge distribution story.
Good: if your compute already runs on Cloudflare Workers, D1 is right there — bindings instead of connection strings, pricing bundled into the Workers ecosystem, and read replication handled by the platform. The Workers + D1 + KV + R2 combination is a genuinely coherent stack.
Watch out for: D1 makes the most sense *from inside* Workers. If your backend runs anywhere else, you're accessing it over HTTP and losing most of the point. You're also adopting the Cloudflare worldview wholesale — great if you want it, constraining if you don't.
2. Litestream + a VPS — the "SQLite was never the problem" option
If what you actually loved was SQLite itself — embedded, zero network hops, one file — the honest alternative is running it where your app runs and replicating for durability. [Litestream](https://litestream.io) streams your SQLite WAL to object storage continuously, giving you disaster recovery for pennies.
Good: reads are function calls, not network requests. No driver quirks, no per-row pricing, the full local SQLite feature set. For a single-node app this is the simplest architecture on this list.
Watch out for: it's replication for recovery, not high availability — failover is a restore, not an instant switch. And you're operating a server again: updates, monitoring, disk space. Fine for one node; the model strains when you need many.
3. Neon — serverless Postgres with the branching workflow
[Neon](https://neon.tech/docs/introduction) is the go-to answer when the conclusion is "we need Postgres, but we liked Turso's pay-for-what-you-use feel."
Good: compute scales to zero when idle, storage and compute are decoupled, and database branching gives you the closest thing to Turso's cheap-database-copies trick in Postgres form — a copy-on-write branch per preview deploy is a genuinely great workflow. Free tier available for side projects.
Watch out for: scale-to-zero means cold starts on the first connection after idle. And it's a database only — your app hosting, and the latency between your app and the database region, are still yours to manage. The multi-region read story is not the same as SQLite replicas at the edge.
4. PlanetScale — when write scale is the actual problem
If you're leaving Turso because of single-writer limits, [PlanetScale](https://planetscale.com/docs) is the opposite extreme: MySQL on Vitess, the sharding layer built for YouTube-scale write traffic.
Good: horizontal sharding that's actually production-proven, excellent schema-change workflow (branch, deploy request, non-blocking migration), and serious operational maturity.
Watch out for: it's aimed squarely at production businesses — PlanetScale retired its free tier in 2024, so hobby projects should look elsewhere. Vitess also imposes some constraints (foreign-key handling has historically been one) that vanilla MySQL doesn't. This is the "we have real revenue and real write load" choice.
5. Supabase — if you want the database plus the batteries
[Supabase](https://supabase.com/docs) is managed Postgres wrapped in a backend-as-a-service: auto-generated REST APIs, auth, storage, realtime subscriptions.
Good: fastest path from zero to a working app backend, huge community, and underneath it all is a real Postgres you can connect to directly with any client. Row-level security keeps authorization in the database.
Watch out for: if you only wanted a database, the BaaS layer is surface area you're not using. Free projects pause after inactivity, and compute-based pricing on paid tiers deserves a read before production. Their [pricing page](https://supabase.com/pricing) has the current details.
6. PandaStack — a real Postgres or MySQL wired into your app hosting
Our angle on this problem is different: most Turso users aren't running a database in isolation — there's an app next to it. PandaStack deploys the app *and* the database together. Push a Git repo (any Dockerfile, or auto-detected buildpacks for Node.js, Python, Go, and more), attach a managed PostgreSQL or MySQL instance — KubeBlocks-orchestrated on Kubernetes, with MongoDB and Redis also available — and the connection string is injected into your app as DATABASE_URL automatically. No credential copying, no separate dashboards for compute and data.
Good: it's a full-featured server database, so every ORM, extension-dependent library, and BI tool just works — the exact toolbox you give up with SQLite variants. Scheduled daily backups with 7-day retention on the free tier (15 on Pro, 30 on Premium), plus manual backups when you want a checkpoint. The free tier includes one database, 5 web services, 5 static sites, and 300 build minutes a month at $0; paid plans are flat and predictable — Pro $15/mo, Premium $25/mo — rather than usage-metered surprise.
Watch out for: there's no edge read replication — your database lives next to your app in the cluster, which is the right latency profile for a classic app+DB architecture, not for the globally-distributed-reads pattern Turso targets. The free-tier database volume is sized for dev and hobby use, free-tier apps scale to zero (cold starts), and we're a newer platform than the incumbents on this list.
How to choose
| Your situation | Pick |
|---|---|
| All-in on Cloudflare Workers | D1 |
| Single-node app, want embedded SQLite + durability | Litestream on a VPS |
| Need Postgres, love branching/preview workflows | Neon |
| Write volume is the bottleneck, revenue-stage product | PlanetScale |
| Want a BaaS: auth + APIs + Postgres in one | Supabase |
| App + database deployed together, flat pricing | PandaStack |
The core question: was Turso your *database* choice or your *architecture* choice? If it was architecture — reads at the edge, database per tenant — stay in the SQLite family (D1, or Turso itself, which remains good at exactly this). If it was just the most convenient cheap database at the time, you'll likely be happier on a boring server database with the full ecosystem behind it.
If your app and its database belong on the same platform anyway, connecting a repo and attaching a Postgres at [pandastack.io](https://pandastack.io) takes a few minutes to evaluate.