Philip O’Toole traces distributed SQLite from rqlite’s first release in 2014 to today’s mix of servers, embedded libraries, and hosted services. The history doubles as a guide to choosing a replication model. Each approach starts with a different requirement for what happens when machines fail or writers disagree.
- Consensus: rqlite and dqlite use Raft, a protocol for agreeing on an ordered log. rqlite sends writes through a leader and requires a majority to acknowledge them. A partitioned minority refuses writes.
- Recovery: Litestream streams SQLite’s write-ahead log to object storage. A single machine serves the application, with a recovery path if it dies.
- Merge: cr-sqlite uses conflict-free replicated data types to let independent writers diverge and later merge. That fits local-first applications that need to keep writing while disconnected.
- Packaging matters: dqlite is a library embedded inside a product. rqlite is a separate server. Hosted platforms add another operational choice around the same storage engine.
Decide how much restoration time the application can tolerate before buying the complexity of a cluster. Then decide whether disconnected writers must remain writable, and how their changes should reconcile. Those answers narrow the design space faster than comparing products under the same SQLite label.
O’Toole writes as rqlite’s creator, so this is a participant’s history. Its architectural value is the clear connection between failure requirements and replication choices.