Turso and libSQL: Edge SQLite with Embedded Replicas

SQLite is the database I trust most and reach for least in production, and the reason is always the same: it lives in one process, on one disk. It is astonishingly fast for local reads, but the moment you need two servers to share the same data, or a serverless function that spins up with no local file, plain SQLite runs out of room. For years the answer was to reach for Postgres and accept the network round trip on every query.

Turso and libSQL are an attempt to keep SQLite's local-first speed while removing that ceiling. In this post I walk through what libSQL actually is, how embedded replicas give you local reads with a synced remote primary, why the remote protocol matters for serverless and the edge, and how the newer Turso Database rewrite changes the picture. Every claim here is checked against the official docs and repository, linked at the end.

What libSQL actually is

libSQL is an open source, open-contribution fork of SQLite, created and maintained by Turso. It exists for a specific reason: SQLite is open source but famously does not accept external contributors. libSQL was forked so the community can add features on top of the same battle-tested engine. It keeps full backwards compatibility — the docs commit to reading and writing the same SQLite file format and to 100 percent compatibility with the SQLite API, while allowing additional APIs on top.

On that base libSQL layers the two things plain SQLite lacks. First, remote access: a libSQL server exposes the database over the network, so clients can talk to it the way they would to Postgres or MySQL, instead of only opening a file on the same machine. Second, embedded replicas, which are the feature that makes the whole design interesting. libSQL also inherits SQLite's core constraints, including the single-writer model — only one write transaction runs at a time.

Embedded replicas: local reads, remote writes

An embedded replica is a full local copy of a remote database, living as a real SQLite file inside your application. Reads are always served from that local file, so they run in microseconds with no network hop. Writes are a different path: by default they are sent to the remote primary, not written to the local file first, and once the primary accepts them the local copy is updated automatically. You get local read latency without giving up a single source of truth.

import { createClient } from "@libsql/client";

// Embedded replica: a local SQLite file for reads,
// a Turso Cloud primary for writes.
const db = createClient({
  url: "file:local.db",               // reads served locally, in microseconds
  syncUrl: "libsql://my-db.turso.io", // writes forwarded to the cloud primary
  authToken: process.env.TURSO_AUTH_TOKEN,
  syncInterval: 60,                   // pull remote changes every 60 seconds
});

// Reads never leave the machine.
const users = await db.execute("SELECT * FROM users WHERE active = 1");

// Writes go to the primary; the local file is then updated automatically.
await db.execute({
  sql: "INSERT INTO users (email, active) VALUES (?, ?)",
  args: ["[email protected]", 1],
});

// Pull the latest remote state on demand.
await db.sync();

The client configuration is where this becomes concrete. You point url at a local file for reads and syncUrl at the cloud primary for writes, then set a syncInterval so the replica pulls remote changes on a schedule. The read-your-writes guarantee matters here: after a write returns successfully, the replica that issued it always sees the new data immediately, even before the next sync. Other replicas only see it after they call sync or hit their interval.

The remote protocol for serverless and the edge

Embedded replicas assume a durable local disk, which serverless and edge runtimes often do not have — a function may start cold with no filesystem to hold a replica. For those cases libSQL speaks a remote protocol over HTTP and WebSockets rather than requiring a persistent local file. The client accepts libsql, http, https, ws, and wss URLs, so the same API that opens a local file can instead issue queries straight to a remote database over a stateless connection.

This is what makes SQLite viable on platforms where a raw file simply is not an option. An HTTP-based protocol suits short-lived, stateless invocations far better than a traditional TCP database connection that expects a long-lived session and connection pooling. You get SQLite semantics from a Vercel function, a Cloudflare-style edge worker, or any environment that can make an HTTPS request, without shipping and mounting a database file alongside your code.

Database-per-tenant at scale

Because a SQLite database is just a file, it is cheap to have a lot of them — and Turso leans into this hard. Instead of one large shared database with a tenant_id column on every table, you can give every user, tenant, or AI agent its own dedicated database. An idle database costs only its storage, because there is no process running when nobody is querying it, which is how Turso Cloud is designed to host millions or even billions of small databases. Isolation, per-tenant backups, and noisy-neighbor safety come almost for free.

libSQL versus Turso Database: the 2025 picture

There is a naming subtlety worth getting right. libSQL and Turso Database are two different projects from the same team. libSQL is the SQLite fork described above — written in C, production-ready, and the foundation of Turso Cloud today. Turso Database is a newer, ground-up rewrite of SQLite in Rust, intended as a drop-in replacement, that goes beyond a fork: it adds concurrent writes via BEGIN CONCURRENT with multi-version concurrency control, an async-first I/O model for serverless and edge, and native support for the database-per-tenant model.

For a new project the team now recommends Turso Database, while libSQL remains the right choice for mission-critical workloads that need a battle-tested foundation today. My own rule is simpler: if I want SQLite's speed on a single box with an optional synced backup, libSQL and embedded replicas are already excellent. If I am designing for the edge, for many isolated tenants, or for write concurrency SQLite never had, the Rust rewrite is the direction to bet on.