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.

SQLite has no built-in network access or replication, and it only allows one writer at a time. Turso works on those limits, but its two different database projects are easy to confuse.

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.

The file model gives you instant reads and backups through 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. It uses the same file format and SQL dialect as SQLite, along with the 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

Embedded replicas are what 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 new SQLite engine written from the ground up in Rust, rather than a fork.

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 and not for production.

Turso’s own guidance sends new experimental projects to Turso Database and mission-critical apps today to libSQL.

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. For production today, I would start with libSQL because it keeps the single-file model and adds the network layer on top.

Want me to talk about your product? You can sponsor this site.