libSQL and Turso: SQLite for production

SQLite runs everywhere. One file, zero network latency, cheap to host. For years that made it perfect for local apps and mobile, but awkward for production web apps.

The gaps were obvious: no built-in network access, no replication, and SQLite only allows one writer at a time. Turso fills those gaps. The landscape is confusing though, because Turso ships two different database projects. Let’s untangle it.

Why SQLite in production now

If you’ve read what is a database, you know relational databases store rows in tables and answer questions with SQL. SQLite does all of that in a single file on disk.

That file model is the superpower. Reads are instant. Backups are a file copy. Hosting costs almost nothing compared to a managed Postgres cluster.

What’s missing is everything around the file. Your app on a VPS in Frankfurt can’t open a SQLite file sitting on a server in Oregon without copying it over the network on every request. You need remote access, replicas close to users, and a path to scale reads without rewriting your app.

libSQL: the open fork

SQLite is open source, but not open contribution. You can’t send pull requests to upstream SQLite and expect them to land. Turso created libSQL as a fork to evolve SQLite in the open.

libSQL is production-ready today. Same file format as SQLite. Same SQL dialect. Same APIs your tools already know. If your app works with SQLite, it works with libSQL.

On top of compatibility, libSQL adds what production apps need:

• Remote access over HTTP
• Embedded replicas that sync with a remote primary
• Native vector search for AI workloads

Think of libSQL as SQLite with the network and replication layers built in.

Getting started with Turso Cloud

Turso Cloud is the hosted service. You get SQLite-compatible databases at the edge, backed by libSQL.

Install the Turso CLI:

curl -sSfL https://get.tur.so/install.sh | bash
turso auth login

Create a database:

turso db create my-blog

Grab the connection URL and an auth token:

turso db show my-blog --url
turso db tokens create my-blog

Install the client in your Node app:

npm install @libsql/client

Connect and run a query:

import { createClient } from '@libsql/client'

const client = createClient({
  url: process.env.TURSO_DATABASE_URL,
  authToken: process.env.TURSO_AUTH_TOKEN,
})

const result = await client.execute('select * from posts')
console.log(result.rows)

On Cloudflare Workers or other edge runtimes, import from @libsql/client/web instead. Same API, HTTP transport underneath.

If you use an ORM, @libsql/client works with Drizzle and Prisma today.

Embedded replicas

This is the feature that sold me on Turso.

An embedded replica is a local SQLite file on your server that syncs with the remote primary. Reads hit the local file at disk speed. Writes go to the cloud and sync back down.

import { createClient } from '@libsql/client'

const client = createClient({
  url: 'file:local.db',
  syncUrl: process.env.TURSO_DATABASE_URL,
  authToken: process.env.TURSO_AUTH_TOKEN,
})

await client.sync()
const posts = await client.execute('select * from posts')

Your app reads from local.db. Turso keeps it in sync with the remote database in the background. You get edge-like read latency without running at the edge.

Turso Database: the Rust rewrite (beta)

There’s a second project, and this is where people get confused.

Turso Database (formerly codenamed Limbo) is a ground-up rewrite of SQLite in Rust. It’s not a fork. It’s a new engine.

It targets async I/O with io_uring, MVCC with BEGIN CONCURRENT for concurrent writes, and deterministic simulation testing. SQLite is single-writer. Turso Database aims to fix that.

It’s in beta. Not for production.

Turso’s own guidance: new experimental projects → Turso Database. Mission-critical apps today → libSQL.

Don’t conflate the two. libSQL is the production fork you deploy now. Turso Database is where SQLite is heading.

libSQL vs Cloudflare D1

Both give you SQLite in the cloud. The choice depends on where you already live.

Pick Cloudflare D1 if your app runs on Cloudflare Workers or Pages. D1 is native to that stack. Bindings, local dev with Wrangler, no extra vendor.

Pick Turso if you want embedded replicas, or if your app runs on Railway, Fly, a VPS, or anywhere else. Turso isn’t tied to one platform.

My rule: already on Cloudflare → D1. Need local-speed reads with cloud sync, or deploying outside Cloudflare → Turso with libSQL.

SQLite finally has a credible production story. libSQL keeps everything you love about the single-file model and adds the network layer on top. Start there.

Related posts about database: