rqlite creator traces twelve years of distributed SQLite

The creator of rqlite has written a first-person retrospective on distributed SQLite, prompted by the fact that people now writing about the category tend to start the story around 2021. His version starts in September 2014, when he published a short post announcing rqlite: SQLite with a Raft log in front of it, replicating every write across a cluster so that losing a node does not mean losing data. The source went on GitHub that same weekend. As far as he can tell, it was the first open-source system to combine Raft and SQLite. Today, he says, the category holds a dozen projects, a few of them venture-funded, two of them acquired.

The need was concrete. A clustered system he worked on at jut.io needed a small amount of relational storage, and there was no good answer to which node should hold it. His team went another way at work, but he kept building rqlite because the problem was general and the solution small. The first version used goraft, the library InfluxDB and etcd used at the time; he joined InfluxDB as a core developer around then. In early 2016 he swapped it for Hashicorp's Raft implementation, which rqlite still uses. The decision that mattered most was made at the start and never changed: rqlite is a CP system. Writes go through the leader, a majority must acknowledge, and a partitioned minority refuses writes. The HTTP API, the read-consistency levels and the snapshotting all followed from that.

He notes two precursors or near-contemporaries. Expensify had replicated SQLite inside its own infrastructure for years with a Paxos-style protocol and released it as Bedrock in 2016. ActorDB, an Erlang system giving each actor its own Raft-replicated SQLite database, appeared around the same time as rqlite. Neither was widely adopted outside its origin, but both show the idea was in the air. What rqlite did, he says, was make it a standalone, general-purpose, open-source thing anyone could run.

The 2017 chapter is dqlite. Canonical built it to give LXD and later MicroK8s an embedded replicated store without running etcd. Mark Shuttleworth called the author once to discuss whether rqlite could be made to work, but it never quite fit. dqlite began in Go and was rewritten in C with its own Raft library. It is the project most similar to rqlite in intent; the difference is packaging. dqlite is a library you embed, rqlite is a server you run.

In early 2021 Ben Johnson, whom the author worked with at InfluxDB, released Litestream. It uses no consensus: it watches the SQLite write-ahead log and streams it to S3, giving disaster recovery for a single-node database at almost no cost. Johnson's argument was that most applications need one machine and a way to recover if it dies, not a cluster. The author says he was right about a great many applications and that the later "SQLite is enough" movement owes a lot to the argument. In his framing, Litestream asks what happens if the machine dies; rqlite asks what happens if it dies and you cannot wait to restore. Fly.io hired Johnson in 2022 and shipped LiteFS, which replicates SQLite at filesystem level with leases from Consul, the first attempt to make replicated SQLite a platform feature. In a final twist, Litestream inspired rqlite's v8.0 approach to handling the SQLite WAL.

Two projects in 2022 took approaches neither rqlite nor Litestream had. cr-sqlite added CRDTs to SQLite as an extension, so multiple writers can diverge and merge without a leader. That is the AP corner of the design space, suited to local-first applications where rqlite's CP guarantees would get in the way. libSQL forked SQLite itself. ChiselStrike, later Turso, wanted to change things inside the engine that the SQLite project, which does not accept outside contributions, would not change. On the fork they built a hosted service with edge replicas. Turso raised venture money, and in 2026 Supabase acquired them. Around the same time SQLite Cloud appeared, offering hosted SQLite replicated with Raft; the author calls it the project closest to rqlite's original design, wrapped in a cloud service. Cloudflare announced D1 in 2022, serverless SQLite inside its edge network, and later put SQLite storage inside Durable Objects. The category, he writes, went from a thing you run to a thing you buy.

He draws three lessons, prefaced with "I think". First, the core was right: SQLite as the storage engine with replication added outside has been reinvented by at least eight teams with different needs and protocols, and nobody has found a reason to stop. Second, the design space has three corners that appeared in order: consensus (rqlite, dqlite), streaming (Litestream) and merge (cr-sqlite and parts of the local-first movement). Each answers a different question, and most arguments are between users about which question is being asked. Third, the money went to the platforms. rqlite, dqlite and Litestream are open source and free, while the projects that raised capital or were acquired turned replicated SQLite into a service with a bill. He calls that the usual fate of infrastructure ideas and says he does not mind, but notes the idea was open source for eight years before anyone sold it. rqlite, he concludes, does what it did in 2014 a good deal better, and remains the choice for a fault-tolerant relational database you can run yourself, understand fully and not pay anyone for.

Key facts

• The author published rqlite in September 2014: SQLite with a Raft log in front, which he believes was the first open-source system combining Raft and SQLite.
• rqlite is a CP system by a decision made at the start: writes go through the leader, a majority must acknowledge, and a partitioned minority refuses writes.
• He sees three design corners that appeared in order: consensus (rqlite, dqlite), streaming (Litestream, 2021) and merge (cr-sqlite, 2022).
• Turso, which forked SQLite as libSQL and sold a hosted service, was acquired by Supabase in 2026, per the author; Cloudflare announced D1 in 2022.
• His conclusion: rqlite, dqlite and Litestream stay open source and free, while the money went to hosted platforms, after the idea was open source for eight years before anyone sold it.

Why it matters

Replicating SQLite has become a crowded category, with a dozen projects by the author's count and at least eight teams having reinvented the same core idea. This is the account of someone who built the first one, and it sets out a map of the field: consensus, streaming and merge as three answers to different questions. It also records how the category moved from software you run to services you buy, which is the author's main argument about where money went.

Who it affects

Developers choosing a way to make SQLite survive a dead machine or serve several nodes. Teams running small services on one machine, teams building local-first apps, and teams who need a fault-tolerant relational store they can run themselves. It also touches those weighing hosted options such as Cloudflare D1, Turso or SQLite Cloud against open-source projects.

How to use it

The post works as a decision guide in the author's own terms. For recovery of a single-node database, Litestream streams the WAL to S3 with no cluster. For strong consistency across nodes, rqlite is a server you run and dqlite is a library you embed. For multiple writers that merge without a leader, such as local-first apps, cr-sqlite takes the AP route. For hosted options he names Cloudflare D1, Turso and SQLite Cloud. His summary of rqlite's niche: a fault-tolerant relational database you can run yourself and understand fully.

How solid is it

This is a personal retrospective by the creator of rqlite, written in first person, and it reflects one participant's view. The first-open-source claim is hedged by him with "as far as I can tell", and his three takeaways are prefaced with "I think". The dates and project histories are his account; the post gives no usage, download or revenue figures and no price or terms for the Turso acquisition. It quotes no outside reactions.

Risks and caveats

The author has a stake: he built and still maintains rqlite, and he frames the field around it, including the claim that dqlite is the most similar project and SQLite Cloud the closest to his original design. The conclusion that the money went to platforms rests on his own selection of examples. He also says he does not mind that outcome, so the post is not a complaint about it. Readers should treat the comparisons between projects as his characterisation, not a benchmark.

“it is worth recording that the idea was open source for eight years before anyone sold it.”

— The author of rqlite, in his twelve-year retrospective