libSQL: a SQLite fork with embedded replicas and a remote server mode

The gap libSQL fills between a local SQLite file and a database server

SQLite is a library, not a service. Every process that opens the same file is a separate client, and there is no network protocol. libSQL keeps the embedded model and adds two things SQLite does not have: embedded replicas, described in the README as a replicated database inside your app, and libsql-server, described as a server for remote SQLite access similar to PostgreSQL or MySQL. The intended audience is a team that already ships SQLite in an application and wants reads served locally while writes go to one authoritative node, without adopting Postgres or MySQL and rewriting queries. The repository layout supports that reading: libsql-server, libsql-replication, libsql-hrana and bottomless are separate workspace members, so replication and backup are not bolted onto the server crate. The README is explicit that this is a fork, not a rewrite, and that it inherits SQLite's fundamental limitations, including the single-writer model.

How the workspace is organized and where replication lives

Cargo.toml defines a workspace with members bindings/c, bindings/wasm, bottomless, bottomless-cli, libsql, libsql-ffi, libsql-hrana, libsql-replication, libsql-server, libsql-sys, vendored/rusqlite and vendored/sqlite3-parser. The C source of the fork itself sits in libsql-sqlite3, and the Rust layer wraps it through libsql-ffi and libsql-sys. That split matters when you debug: a crash inside query execution is a libsql-sqlite3 problem, while connection handling and the HTTP surface belong to libsql-server. libsql-replication is the crate that carries the write-ahead log between nodes, and bottomless is the backup component, with bottomless-cli as its command-line entry point. The README also lists a virtual write-ahead log interface as one of the core extensions, which is the hook that makes shipping the WAL to another process possible. Note that libsql-shell and tools/fuzz are excluded from the workspace, so they are not built by a plain workspace build.

Installing libSQL and running a first query

The repository does not publish a single install command for the whole project. The README points to official drivers for TypeScript and JavaScript, Rust, Go, and Go without CGO, and marks the Python and C bindings as experimental. Pick the driver for your language and follow that repository. To build the server from source, the Dockerfile shows the intended path: it installs libclang-dev, clang, build-essential, tcl, protobuf-compiler, file, libssl-dev, pkg-config, git and cmake, then reads the channel from rust-toolchain.toml and sets it as the default toolchain before building. The build command used in the image is:

cargo build -p libsql-server --release --locked

An ENABLE_FEATURES build argument lets the image add features when it is non-empty, otherwise the plain build runs. The same Dockerfile also builds bottomless-cli with cargo build -p bottomless-cli --release --locked, which is a sign that the backup tool is expected to ship alongside the server. A docker-compose directory and an entrypoint script, docker-entrypoint.sh, exist at the top level, so containerized startup is a supported path rather than an afterthought. What you should see after a successful build is a server binary in the target/release output; the README does not document a first query against it, so check the docs directory and the Turso docs site for the exact request format before assuming an endpoint.

Drivers: official, experimental, and what that means for production

The README separates official drivers from experimental ones, and the distinction is not cosmetic. TypeScript and JavaScript, Rust, Go, and Go without CGO are listed as official. Python and C are listed as experimental, and the PHP client is listed under community drivers. If you are writing Python, you are on a binding the project itself labels experimental, which means the API can move without a deprecation cycle. The C binding lives at bindings/c and is also experimental, so a C application that wants libSQL should expect to track the workspace version, currently 0.10.0-pre.4 in Cargo.toml, rather than a stable ABI. The JavaScript and Rust paths are the ones with the most direct support in the repository, which is consistent with the topics listed for the project: database, embedded-database, rust, sqlite, webassembly.

The single-writer limit and the project's own advice about new work

The README carries an important notice near the top: libSQL is a fork of SQLite and inherits its fundamental limitations, and Turso database is a separate project, a SQLite-compatible database rewritten in Rust, not a fork, currently in beta. The same notice says that if you are starting a new project you probably want to look into Turso, and that libSQL is actively maintained but new features are being developed in Turso. The last push to this repository was on 2026-09-16, so the code is not dormant, but the direction of feature work is stated plainly. The practical consequence is that libSQL is a reasonable target for existing SQLite deployments that need replicas or a network endpoint, and a questionable target for a greenfield project that expects concurrent writes. No amount of tuning a fork removes the single-writer constraint that the fork inherits.

libSQL against SQLite and against a client-side SQLite wrapper

Compared with upstream SQLite, libSQL adds the extensions listed in the README: an ALTER TABLE extension for modifying column types and constraints, randomized ROWID, WebAssembly user-defined functions, passing the SQL string down to virtual table implementations, and the virtual write-ahead log interface. Those are additive. The replication and server pieces are the real divergence. Compared with a JavaScript wrapper such as better-sqlite3, the difference is architectural rather than syntactic: better-sqlite3 is a synchronous binding to SQLite in one process, with no replication layer and no server mode, while libSQL ships libsql-server and libsql-replication as workspace crates so a write can be shipped to other nodes. If your requirement is only faster local queries from Node, a plain binding is a smaller dependency. If your requirement is a local replica that stays current with a primary, that is the case libSQL was built for.

Licence, maintenance and upgrade cost

The repository is MIT licensed, and Cargo.toml sets license = "MIT" for the workspace package, so the Rust crates and the SQLite fork carry the same permissive terms. MIT places few conditions on redistribution, but the fork nature means you should track upstream SQLite changes yourself; libSQL is not automatically rebased for you. Upgrade cost concentrates in three places: the workspace version, currently 0.10.0-pre.4, which is a pre-release and can break API expectations; the experimental bindings, where Python and C carry no stability promise; and the server, whose recent release tags are libsql-server-v0.24.32 from 2025-02-14, libsql-server-v0.24.31 from 2025-01-06 and libsql-server-v0.24.30 from 2024-12-17. The gap between the pre-release workspace version and the 0.24.x server tags is worth understanding before you pin anything. This is a description of the licence text, not legal advice; have counsel review redistribution if you embed the fork in a shipped product.

Editorial conclusion

Adopt libSQL when you want SQLite's file format and single-writer semantics but need a replica inside the application process or a network endpoint that speaks the same SQL. Skip it if you need concurrent writers, because the README states libSQL inherits SQLite's single-writer model and that new features are being developed in Turso instead. Before committing, verify which driver is official rather than experimental for your language, and confirm the libsql-server version you intend to run against the newest release tag, libsql-server-v0.24.32.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tursodatabase/libsql on GitHub