libSQL keeps SQLite's file format and its single-writer model

The project's own note tells you not to start here

The most important paragraph in the file is an admonition at the top, and it is about the difference between two projects from the same team. libSQL, this repository, is an open-source fork of SQLite that extends it with things like embedded replicas and remote access, and it inherits SQLite's fundamental limitations, with the single-writer model named first. Turso is a SQLite-compatible database rewritten from scratch in Rust, not a fork, and it goes beyond what any SQLite fork can offer, including concurrent writes and bi-directional sync with offline support; it is currently in beta. The file then says that if you are starting a new project you probably want to look at Turso, and that while libSQL is actively maintained, new features are being developed in Turso. The last push recorded for this repository is 2026-10-17. So adopting libSQL is a decision to stay inside SQLite's architecture on purpose.

Three version numbers, and none of them describes the same thing

Pick a version in this project and you will pick from three schemes. The tags are named for the server component, libsql-server-v0.24.32 published on 2025-02-14, with 0.24.31 and 0.24.30 before it. The workspace manifest declares its own version as 0.10.0, which is the library side. And the shell session printed in the documentation says libSQL version 0.2.1, based on SQLite version 3.43.0, dated 2023-05-23, which is older than the branch you would clone today. Nothing reconciles them in the visible documentation. If you are pinning a dependency, pin the crate or the server image you actually consume, and do not read the sample shell output as a statement about what you have installed. It is a useful illustration of the shell's messages and nothing more.

The compatibility promise is about your data, not about the distribution

The stance on SQLite compatibility is split three ways and the third part is the one that will bite. On the file format, libSQL will always be able to ingest and write the SQLite file format; the project would like to add extensions such as encryption and checksums that require the file itself to change, and commits to doing so in a way that generates standard SQLite files when those features are not used. On the API, it keeps full compatibility with the SQLite API and may add more. On being embedded, it will always run inside your process without a network connection, but the distribution may change so that object files are generated instead of a single .c file with its header. That last clause matters more than it reads: the amalgamation you vendor today is not promised for tomorrow.

The extensions are the reason to be here, not a speed claim

Nothing in the file claims a benchmark, so the argument for a fork has to be made from the feature list, and the list is specific. There is an ALTER TABLE extension for modifying column types and constraints, which upstream SQLite does not offer, plus randomised ROWID, WebAssembly user defined functions, a mechanism to pass the SQL string down to a virtual table implementation, and a virtual write-ahead log interface. Those are the things a fork buys you. Note that they are linked unevenly: some point at documentation, the randomised ROWID item points at an issue, and the virtual table and virtual WAL items point at pull requests, so read the list as partly shipped and partly intended. The full description is in the extensions document inside the libsql-sqlite3 directory, and that file rather than the top-level list is where you should confirm what a given build contains.

Drivers come in three tiers, and the experimental C one is the base

The driver list is graded, which tells you where the risk is. Official are the TypeScript and JavaScript client, Rust, Go, and a second Go client with no CGO. Experimental are Python and C. Community are PHP, plus D and Ring, both marked experimental and both built on the C driver. That last relationship is the one to keep in mind: when the community bindings are based on the experimental C driver, an instability in that layer shows up in every language built on it, and a D developer and a Ring developer inherit the same foundation. For Go there is a real decision rather than a preference, since a CGO client and a no-CGO client are different libraries with different build requirements, and the no-CGO one is what you want if cgo is not welcome in your build. On the GUI side, Beekeeper Studio, TablePlus and Dataflare are desktop tools, with Dataflare the paid one, and Outerbase and libSQL Studio run in the browser.

The Rust workspace vendors its own rusqlite and excludes its C sources

The manifest shows how much of SQLite this project carries. The workspace has thirteen members, and two of them are vendored copies, vendored/rusqlite and vendored/sqlite3-parser. The rusqlite dependency is renamed to libsql-rusqlite and enabled with a feature list that includes libsql-experimental, modern_sqlite, load_extension and hooks, so the Rust side is not a thin binding to whatever libsqlite your distribution ships. The exclude list keeps the C and shell trees out of the Cargo build, including libsql-sqlite3/ext/crr, libsql-wasi, libsql-shell, and the tools for rebuilding the log and fuzzing. There is a rust-toolchain.toml, the release profile sets one codegen unit and keeps panics unwinding, and a separate dist profile inherits release with thin LTO for the artifacts cargo dist produces.

The container build compiles Rust and C from source, toolchain first

Building locally is one command, and it produces the SQLite-compatible C library and the tools:

cargo xtask build

The shell is then run from the libsql-sqlite3 directory, and it opens on a transient in-memory database until you use .open on a file. Docker is documented separately, and the tree carries a Dockerfile, a development one, a musl one, a compose directory, an entrypoint script, a wrapper script and a fly.toml. The Dockerfile is the interesting part. It starts from a slim Debian image, installs clang, libclang-dev, build-essential, tcl, protobuf-compiler, cmake, libssl-dev, pkg-config, git and file, and then, before anything is compiled, copies rust-toolchain.toml in and extracts the channel from it to set as the default toolchain, because the file explains that otherwise cargo-chef builds dependencies with the wrong toolchain and reinstalls it at every stage. The build itself is a planner and a builder pair, and it takes a BUILD_DEBUG argument plus an ENABLE_FEATURES argument that decides which features go into the libsql-server binary.

Editorial conclusion

libSQL fits a team that wants SQLite's file format and C API plus remote access or an in-app replica, and especially one whose blocker is one of the documented extensions. It does not fit a workload that needs concurrent writers, since the single-writer model is inherited from SQLite, and the project's own note says new feature work is going into Turso. Before you adopt it, resolve the versioning, because the tags track libsql-server at 0.24.32 from 2025-02-14 while the workspace sits at 0.10.0 and the shell banner in the README still reads 0.2.1. Then check the driver you need against the three tiers, since Python and C are experimental and the community bindings are built on top of that experimental C driver. Finally, read the distribution promise: the file format stays standard, but the packaging may stop being a single .c file.

Frequently asked questions

Official sources

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