Rqlite creator Philip O'Toole has published a 12-year retrospective on the open-source database, describing how an experiment that placed the Raft consensus protocol in front of SQLite grew alongside a wider category of replicated and distributed SQLite systems.
O'Toole released rqlite on GitHub in September 2014 after encountering a practical infrastructure problem: a clustered application needed a small relational store, but assigning that data to one machine created an obvious failure point. Rqlite's answer was to route writes through a cluster leader and replicate them through a Raft log before acknowledging them.
That design makes rqlite a consistency-and-partition-tolerance, or CP, system. A majority of nodes must acknowledge writes, and a minority isolated by a network partition will refuse them. The core choice has remained intact even as the project changed its Raft implementation, developed an HTTP interface and added read-consistency options and snapshot handling.
The retrospective also places rqlite among parallel and later efforts. O'Toole noted that Expensify had used a Paxos-style method to replicate SQLite internally before releasing Bedrock in 2016, while ActorDB paired individual SQLite databases with Raft around the same period. Canonical later created dqlite as an embeddable replicated store for products including LXD and MicroK8s. Rqlite, by contrast, remained a server intended to run beside an application.
Other projects addressed different failure models. Litestream, released in 2021, streams SQLite's write-ahead log to object storage so a single database can be restored after a machine failure. It does not maintain a consensus cluster. Fly.io's LiteFS moved replication to the filesystem layer, while cr-sqlite used conflict-free replicated data types to support divergent writers that can later merge. LibSQL forked SQLite to permit engine-level changes and became the basis for Turso's hosted service.
O'Toole groups these approaches into three broad designs: consensus for strongly consistent clusters, streaming for inexpensive recovery from a single writer, and merging for applications that accept eventual consistency. Each solves a different operational problem, so choosing among them depends on whether an application prioritizes immediate failover, simple restoration or independent writers.
The account is a first-person history from rqlite's creator, not an independent market survey. Its useful contribution is a technical map of how one storage engine has been wrapped in distinct replication models. Twelve years after its first release, rqlite remains positioned as a self-hosted, fault-tolerant relational database, while commercial platforms have turned related ideas into managed services.
The distinctions also clarify why the phrase distributed SQLite can conceal substantially different guarantees. A recovery stream does not offer the same availability characteristics as a quorum-backed cluster, while a merge-oriented system deliberately accepts behavior that a strongly consistent service prevents.
