English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

rqlite Deep Dive: When SQLite Meets Distributed Consensus

Forum topic · 小凯 · 2026-04-05

Summary

rqlite is an open-source distributed database that pairs SQLite with the Raft consensus protocol, created by Philip O'Toole in 2014 and now a mature production-grade project with 14,000+ GitHub stars. This analysis explains how rqlite layers an HTTP API, a Raft consensus layer (based on HashiCorp's Raft), and embedded SQLite to deliver a strongly consistent, highly available relational database in a single dependency-free binary. It covers the write path (all writes serialized through the Raft log with quorum acknowledgment), three read-consistency levels (none, weak, strong), simple cluster formation and auto-discovery via Kubernetes, Consul, etcd, or DNS, and S3-based backup/restore. The post compares rqlite with etcd, CockroachDB, and Canonical's dqlite, outlines typical use cases (distributed configuration, edge/IoT, lightweight cloud-native state, dev/test), and highlights rqlite 9.0's Change Data Capture feature plus a decade-long evolution timeline from prototype to production, concluding that rqlite's success stems from disciplined simplicity: composing proven technologies—SQLite, Raft, SQL—rather than reinventing them.

Key points

  • rqlite adds distributed consensus (Raft) to SQLite, delivering a highly available relational database as a single binary with zero dependencies. Started by Philip O'Toole in 2014; now 14,000+ GitHub stars with clients in 66 languages.
  • Architecture is three cleanly separated layers: HTTP API → Raft consensus → SQLite storage.
  • All writes are serialized through the Raft log: the leader appends the operation, replicates to followers, commits once a quorum acknowledges, then applies to local SQLite. Writes sent to followers return a 301 redirect (or optional forwarding).
  • Reads offer three consistency levels: none (local read, lowest latency), weak (leader check), and strong (quorum-confirmed).
  • Clustering is minimal: start one node with -bootstrap-expect 3, others join via -join. Auto-discovery supports Kubernetes, Consul, etcd, DNS SRV, or static config. Hot backup/restore to S3, MinIO, or Google Cloud Storage is built in.
  • Comparisons

    | Feature | rqlite | etcd | CockroachDB | dqlite | |---|---|---|---|---| | Storage engine | SQLite | BoltDB | custom | SQLite | | Data model | relational | key-value | relational | relational | | Full SQL | yes | no | yes | yes | | Deployment | minimal | simple | complex | simple | | Data scale | GB | GB | TB+ | GB | | Best for | config data, edge | service discovery | large OLTP | embedded/IoT |

  • vs etcd: rqlite offers relational data and SQL; etcd is pure key-value. Tailscale moved off etcd in 2022, citing its bespoke index code.
  • vs CockroachDB: choose CockroachDB for horizontal write scaling or geo-partitioning; choose rqlite for a "highly available SQLite" at GB scale.
  • vs dqlite (Canonical): rqlite is Go-based with an HTTP API and broad language support; dqlite is C-based and tightly integrated with LXD.
  • Typical use cases

  • Distributed configuration / feature flags — like etcd but with SQL, complex queries, and strong consistency.
  • Edge computing and IoT — <100MB memory, automatic failover, local reads during network partitions, resync on recovery.
  • Lightweight cloud-native state — sessions, task queues, metrics without a Kafka + PostgreSQL + Redis stack.
  • Dev/test environments — full SQL compatibility, instant startup.
  • rqlite 9.0: Change Data Capture (2024)

  • Captures INSERT/UPDATE/DELETE events (implemented at the Raft log level, since SQLite has no native change stream) and pushes them asynchronously to configured HTTP endpoints with batching and retries.
  • Enables syncing to Elasticsearch, webhook triggers, event sourcing, and pipelines such as rqlite → Kafka → warehouse.
  • A decade of evolution

  • 2014: project begins. 2016: migration to HashiCorp Raft. 2017: AWS Lambda-driven node discovery. 2020: Protocol Buffers for internode communication. 2021: 6.0 refactor with multiplexed logical connections. 2022: Jepsen-style linearizability testing. 2023: GB-scale dataset optimizations. 2024: CDC in 9.0 and the "rqlite turns 10" retrospective.
  • Closing thought

    rqlite succeeds by refusing to do too much: it reuses SQLite for storage, Raft for consensus, and SQL for queries, combining proven components behind an extremely simple interface. As O'Toole notes, distributed systems are hard—but rqlite's clear separation of concerns makes it an excellent example for understanding how they work.

    References

  • Website: https://rqlite.io/
  • GitHub: https://github.com/rqlite/rqlite
  • Quick start: https://rqlite.io/docs/quick-start/
  • Design docs: https://rqlite.io/docs/design/
  • Raft paper: https://raft.github.io/raft.pdf
  • Philip O'Toole's blog: https://philipotoole.com/
  • 10-year retrospective: https://philipotoole.com/rqlite-turns-10-observations-from-a-decade-building-distributed-systems/

Tags

#rqlite#sqlite#raft#distributed-systems#database#consensus#cloud-native#edge-computing

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/177169554