rqlite is a lightweight, distributed DBMS built on top of [SQLite](https://www.sqlite.org/). rqlite uses the [Raft protocol](https://raft.github.io/) to achieve consensus across multiple instances of the SQLite database, ensuring that every change made to the system is made to a quorum of SQLite databases, or none at all. For a detailed description of much of rqlite functionality, consult the [SQLite entry] (https://dbdb.io/db/sqlite).
rqlite was originally a prototype application, showing how the Raft consensus algorithm could be applied to various software state machines -- in this particular instance a SQLite database. It has since developed into a full relational database management system.
rqlite is primarily queried via its HTTP(S) API. A query is formed by encapsulating a SQL statement in a HTTP request. And when using the "on disk" mode of rqlite, the SQLite database can also be queried directly.
rqlite offers the same Views support as SQLite.
rqlite provides data durability via the Raft consensus system. Every change made to the SQLite database is written to the Raft log, and that log is persisted to disk. In the event of a restart or recovery operation, the SQLite database is completely rebuilt from the data contained in the Raft log.
Since rqlite uses SQLite as its storage engine, it performs Joins in the same manner as SQLite, *within a single rqlite node*. It is important to note however, that even though rqlite supports clustering, it does not support Joins across rqlite nodes in that cluster.
Since rqlite uses SQLite as its storage engine, it offers the same storage model as [SQLite](https://dbdb.io/db/sqlite).
Since rqlite uses SQLite as its storage engine, it can make full use of SQLite Indexes
rqlite supports both in-memory and disk-oriented storage. The SQLite database can be stored on disk, or in memory. The Raft log is stored on disk.
rqlite supports the relational data model, since it uses [SQLite](https://dbdb.io/db/sqlite) as its storage engine.
rqlite's system architecture is comprised of 3 distinct subsystems: the HTTP serving layer, the Raft consensus layer, and the (embedded) SQLite database. The HTTP layer is responsible for responding to queries, and returning results. The Raft consensus layer controls communication between nodes, implementing the distributed consensus system. Once a change to the database has been committed to the Raft log on each node, each node then makes the change to the last subsystem, which is the embedded SQLite database.
Linux, OS X, Windows