Learn about the design and implementation of rqlite

You can find details on the design and implementation of rqlite from these blog posts (in particular this post and this post).

Understanding the content of this page is not required to operate rqlite, but may be of interest to people who wish to learn more about its design and operation.

Design Presentations

Node design

The diagram below shows a high-level view of a rqlite node. node-design

File system


The Raft layer always creates a file – it creates the Raft log. This log stores the set of committed SQLite commands, in the order which they were executed. This log is authoritative record of every change that has happened to the system. It may also contain some read-only queries as entries, depending on read-consistency choices. Since every node in an rqlite cluster applies the entries log in exactly the same way, this guarantees that the SQLite database is the same on every node.


By default, the SQLite layer doesn’t create a file. Instead, it creates the database in memory. rqlite can create the SQLite database on disk, if so configured at start-time, by passing -on-disk to rqlited at startup. Regardless of whether rqlite creates a database entirely in memory, or on disk, the SQLite database is completely recreated everytime rqlited starts, using the information stored in the Raft log.

Log Compaction and Truncation

rqlite automatically performs log compaction, so that disk usage due to the log remains bounded. After a configurable number of changes rqlite snapshots the SQLite database, and truncates the Raft log. This is a technical feature of the Raft consensus system, and most users of rqlite need not be concerned with this.

Last modified January 4, 2023: More updates (c202f92)