rqlite: SQLite with a Raft consensus layer wrapped around it

Starting a node with one docker command

The README's quick start is three steps and no configuration file. Step one starts a node that listens on port 4001:

docker run -p 4001:4001 rqlite/rqlite

That image pulls the whole database server. The repository tree shows why there is nothing else to install: `store/` holds the Raft-backed store, `cluster/` the membership and bootstrap logic, `http/` the API handlers, `queue/` the write queue, `snapshot/` and `cdc/` the streaming pieces, and `auth/` the credential handling. The project describes itself as a single binary with no external dependencies, which is accurate for the deployable artifact rather than for the codebase, which is a large Go program split across those directories.

The README also points at a prebuilt binary path and a full Quick Start guide on rqlite.io for people who would rather not use Docker. The repository is not archived and the last push was on 2026-09-18, with v10.3.5 released the same day, so this is a version line that still moves.

Creating tables over HTTP instead of a driver

Steps two and three of the quick start use curl. This is the part that surprises people coming from a database driver: rqlite is an HTTP service first, so the first thing you write against it is an HTTP request.

curl -XPOST 'localhost:4001/db/execute?pretty' -H 'Content-Type: application/json' -d '[
     "CREATE TABLE foo (id INTEGER NOT NULL PRIMARY KEY, name TEXT)",
     "INSERT INTO foo(id, name) VALUES(1, \"fiona\")"
]'

The body is an array of SQL statements, and the README is explicit that these run atomically within a single request. That is a real difference from sending statements one at a time to a local SQLite file: a multi-step write either lands whole or not at all, so a failure in statement three does not leave you with the side effects of statements one and two. The `?pretty` parameter is a debugging convenience for readable output on the terminal.

Reading uses the `db/query` endpoint with a URL-encoded query string:

curl -G 'localhost:4001/db/query?pretty' --data-urlencode 'q=SELECT * FROM foo'

Because the interface is HTTP, any client that can make a request works. The README also lists a built-in console app, a CLI, and client libraries as separate entry points for people who prefer them to raw curl.

What the Raft layer replicates

SQLite on its own is a library linked into a process, with one file and no notion of a second machine. rqlite keeps SQLite as the storage engine and puts a Raft consensus implementation in front of it, which is what makes the README's comparison to etcd a fair one rather than a marketing flourish. You get leader election, replicated writes and fault tolerance while keeping relational modelling, which is the thing the README argues you give up when you pick a key-value store.

Full SQL support comes from SQLite itself, including full-text search through FTS5 and the JSON functions. Beyond that, rqlite can load SQLite extensions, and the README names two concrete ones: `sqlite-vec` for vector search and `sqlean` for crypto and similar extras. That extension mechanism is the most interesting lever in the design. Because the storage engine is the same one a single-process application would use, the SQL surface available to you is the SQL surface you already know, with additions bolted on rather than a separate query language to learn.

The repository topics confirm the shape of the system: consensus, raft, distributed-systems, fault-tolerance and relational-database, in a Go project.

Read consistency and queued writes as tunable settings

Once writes are replicated through Raft, a reader can ask for a node that has not yet seen the latest committed write, and rqlite lets you decide how much that bothers you. The README lists tunable consistency and durability under developer experience, linking to pages on read consistency and queued writes. In practice this means the consistency level is a property of the request rather than a global setting chosen once at startup.

Queued writes are the more interesting half. A write can be accepted before the leader has committed it to the log, which trades durability for latency. That is the right trade in some workloads and the wrong one in others, and being able to choose per request is more useful than picking one behaviour for the whole database.

Change data capture is listed alongside these as a way to stream database changes to an external system. The `cdc/` directory in the tree is where that lives. For anyone building a system where other services need to react to committed data, CDC turns the database into an event source rather than something every consumer polls.

Hot backups to S3, MinIO and Google Cloud

The backup story is unusually concrete for a project at this level of polish. The README lists hot backups as effortless, automatic backups to AWS S3, MinIO and Google Cloud, restore directly from a SQLite file, and restore from cloud storage. Since the on-disk format is SQLite all the way down, a plain file can be restored with SQLite's own tooling, which removes a class of vendor lock-in problems that usually come with clustered databases.

Clustering is documented separately, with guides for Kubernetes, Docker Compose, Consul, etcd and DNS as discovery mechanisms. That list matters because automatic clustering turns out to be one of the harder parts of running a replicated store in production, and having several documented options means you can pick the one matching the infrastructure you already run rather than adopting a new service for the database.

Security documentation covers end-to-end encryption with TLS plus authentication and authorization controls, and the repository has an `auth/` directory to match.

Where the README stops and the docs start

The README is a good advertisement and a thin manual. It gives you a working node in one command, a create-and-insert round trip, and a feature list with links. Everything a production decision needs is one hop away: the Quick Start guide, the clustering page, the API reference, the CLI page, the backup guide, the extensions guide and the CDC guide.

That split is worth naming plainly because it affects how you evaluate the project. If you are choosing between rqlite and a hosted relational database, the deciding questions are about read consistency, write durability and cluster formation, and none of those are answered on the README page. They are documented on rqlite.io, which you would need to read regardless.

The repository itself is a useful read for the questions the docs leave open. `system_test/` and `testdata/` suggest the project's own tests cover cluster behaviour, and the README links to an article on how rqlite is tested, which is unusual transparency for a database project.

Editorial conclusion

rqlite earns its keep when the shape of the problem is a small relational dataset that has to survive node loss and can be reached over HTTP from several places. The Raft layer handles replication, leader election and failover, and SQLite underneath keeps the query language familiar. The cost is that you are running a distributed system on purpose: read consistency and durability are settings you pick per query, and the documentation on rqlite.io covers far more than the README does. Start with the single node quick start, then read the clustering and read consistency pages before deciding how many nodes you actually want.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rqlite/rqlite on GitHub