Twelve Years of Distributed SQLite

In September 2014, Philip O'Toole published a short post announcing rqlite, a system that put a Raft consensus log in front of SQLite and replicated every write across a cluster. The source code went on GitHub that same weekend. As far as he can tell, it was the first open-source system to combine Raft and SQLite. Nobody else was doing it, and for several years, nobody else tried [1].

Today, distributed SQLite is a category with a dozen projects, a few venture-funded, two acquired. O'Toole wrote down the history this week, and it is worth reading because the story of how infrastructure categories form is rarer than you might think [2].

The three corners of the design space

O'Toole identifies three approaches that appeared in chronological order:

Consensus first (2014): rqlite and dqlite. One leader, strong consistency, a cluster. Writes must go through the leader, a majority must acknowledge, a partitioned minority refuses writes. rqlite is a CP system in CAP-theorem terms. Canonical built dqlite in 2017 for LXD and MicroK8s, wanting an embedded replicated store without running etcd. Mark Shuttleworth personally called O'Toole to see if rqlite could work, but it never quite fit [3].

Streaming second (2021): Ben Johnson released Litestream, which does not use consensus at all. It watches the SQLite WAL and streams it to S3, giving you disaster recovery for a single-node database at almost no cost. His argument was that most applications do not need a cluster, they use one machine and need a way to recover if it dies. He was right about a great many applications [4].

Merge third (2022): cr-sqlite added CRDTs to SQLite as an extension, so multiple writers could diverge and merge without a leader. This is the AP corner, suited for local-first applications where consensus guarantees would be a hindrance [5].

Each is correct for a different question. Litestream answers: what if the machine dies? rqlite answers: what if the machine dies and I cannot wait to restore? cr-sqlite answers: what if I have many writers and no reliable network between them? [6].

When the money arrived

The open-source projects, rqlite, dqlite, and Litestream, are free. The money went to the platforms. Turso forked SQLite itself as libSQL, built a hosted service with edge replicas, raised venture capital, and in 2026 Supabase acquired them. Cloudflare announced D1 in 2022, SQLite as a serverless database inside their edge network, and later put SQLite storage inside Durable Objects [7].

O'Toole's observation is dry and accurate: "The category had gone from a thing you run to a thing you buy. The projects that raised the capital or got acquired are the ones that turned replicated SQLite into a service with a bill." He does not mind. But he notes the idea was open source for eight years before anyone sold it [8].

Why SQLite

The core insight, validated by at least eight independent teams with different needs and different protocols, is that SQLite as a storage engine with replication added on the outside works. Nobody has found a reason to stop doing it [9].

SQLite is the most widely deployed database in the world. It runs on every phone, every browser, every operating system. It is a single file, requires no server, and has a public domain license. Adding replication to it gives you a distributed database without the operational complexity of PostgreSQL, MySQL, or Cassandra. For a huge class of applications, that is enough [10].

rqlite is still here

rqlite still does the same thing it did in 2014, a good deal better, and it is still the thing you reach for when you want a fault-tolerant relational database you can run yourself, understand fully, and not pay anyone for. Twelve years in, O'Toole is content with that position [11].

That is a good position to be in. The category O'Toole started is now worth real money, but the original tool is still free, still maintained, and still solving the problem it was built to solve. Not many infrastructure projects get to say that after twelve years.