17,794 stars · MIT, from the repository sidebar · v10.6.0 (2026-10-12), read from /releases/latest as a yearless '12 Oct 13:02' and settled as this year because the date is in the past and ungh's pushedAt is 2026-10-15T11:35:48Z · Track this in Scout
Runs one small single-file database across several machines so a single failure does not take it down.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You start it on three or five machines and they agree on one leader. Your program talks to it over HTTP instead of opening a file. Every write is agreed by a majority of the machines before it counts, so all of them hold the same data. Reads can be set to be fast or to be strictly current, and writes can trade durability for speed. Because SQLite is underneath, you get real SQL, text search and JSON, and you can load SQLite extensions such as vector search. It can form a cluster by itself through Kubernetes, Docker Compose, Consul, etcd or DNS. It takes hot backups and can send them to S3, MinIO or Google Cloud, and restore from a plain SQLite file. The newest release is v10.6.0, from 12 October 2026, and code landed this morning. What it does not do is make writes faster. The project says so in its own words: every write goes through the leader, so there is no scaling for writes at all, and transactions written with BEGIN and COMMIT are officially unsupported.
Why it matters
Who it suits. Anyone running a small service on a single machine who has realised that the database file is the thing with no second copy. It also suits anyone who wants shared settings or state across a handful of servers and does not want to install PostgreSQL to get it. Skip it if the application writes constantly, because consensus on every write is the wrong shape for that, and skip it if you need real transactions.
Verdict. A sensible and narrow answer to a real fear, and the honest framing is availability rather than speed. The project is unusually clear about what it is not, which saves the afternoon that reading the code would otherwise cost. Three things to weigh. Write speed is lower than plain SQLite because each write makes two round trips to a majority of nodes. The practical cluster size is about eleven voting machines, with read-only copies beyond that. And on Linux it needs glibc 2.34 or newer, which rules out older distributions. tursodatabase/libsql at 17,200 stars is a different answer to a neighbouring question: it forks the SQLite engine itself and is open to outside contributions, which this project does not attempt. canonical/dqlite at 4,400 stars does the same job as a C library you embed in your own program, so there is no separate service and no HTTP call, at the price of writing C.
- One small program with no dependencies, and a cluster that can form itself without a configuration file.
- Backups to S3, MinIO or Google Cloud are built in, and a restore can start from an ordinary SQLite file.
- Read consistency and write durability are both adjustable, so a slow read can be made fast where it does not matter.
- Writes are slower than plain SQLite and do not scale at all, because every one goes through the leader.
BEGINandCOMMITtransactions are officially unsupported, which rules out some applications outright.- About eleven voting machines is the practical ceiling, and Linux needs glibc 2.34 or newer.
- tursodatabase/libsql
A fork of the SQLite engine itself, open to outside contributions, at 17,200 stars, under an MIT licence; it changes the engine rather than replicating it.
Track this in Scout - canonical/dqlite
Adds replication and automatic failover to SQLite as a C library inside your own program, at 4,400 stars, under a modified LGPLv3.
Track this in Scout
docker run -p 4001:4001 rqlite/rqlite