RedisRaft makes several Redis instances behave like one consistent database

Several Redis servers, one consistent dataset

RedisRaft is a Redis module that implements the Raft consensus algorithm, and the purpose it states is creating strongly-consistent clusters of Redis servers. The description puts it plainly: a Redis module that makes it possible to create a consistent Raft cluster from multiple Redis instances.

The problem it addresses is the one Redis's own replication does not solve. Asynchronous replication keeps a replica running while the primary is down, and a write that has been acknowledged can be lost. For a cache that is fine. For a dataset where a read must never see a value that a later write overwrote, it is not.

Raft replaces that with a replicated log. Every write is an entry agreed by a majority of the cluster, and every node applies the log in the same order, so the nodes converge on the same state. Reads are answered from that state, which is what makes the cluster strongly consistent rather than eventually consistent.

The implementation detail worth knowing is that the consensus code is not written inside this repository. The Raft algorithm is provided by a standalone Raft library, redislabs/raft, which is a fork of the original library created by Willem-Hendrik Thiart and is now maintained by Redis Ltd. That split means the module is the Redis integration, and the protocol implementation is maintained elsewhere.

The audience is operators who need consistency guarantees from Redis specifically, and who are willing to run a module rather than a stock server.

Consistency and partition tolerance, at the cost of availability

The main features list is short, and the first item states the trade in the language of CAP: strong consistency, where this system prioritizes consistency and partition-tolerance.

That is the design decision, and it has a direct operational consequence. In a network partition, a Raft cluster keeps serving the side of the split that holds a majority of the nodes, and the minority side stops accepting writes rather than risk two nodes accepting conflicting writes. Availability is given up on the minority side. A cluster where both halves keep accepting writes is a cluster with two histories, which is exactly what the algorithm exists to prevent.

The other features are practical consequences of running a replicated log in Redis. Support for most Redis data types and commands means the cluster is not a special-purpose store; you use it as you would use Redis, and the commands are executed in a strongly-consistent manner using the Raft protocol, as the README puts it, with the supported list in docs/Using.md.

Dynamic cluster configuration, adding and removing nodes, matters because membership changes in a Raft cluster are themselves consensus decisions.

Snapshots for log compaction address the fact that a replicated log grows forever. A snapshot lets the cluster discard the log prefix it no longer needs, at the cost of a node having to load state from a snapshot rather than replay entries.

And the last feature, configurable quorum or fast reads, is the one that determines the latency and consistency of a read. A quorum read waits for a majority, which is consistent. A fast read answers from the local node without waiting, which is quicker and is the classic read-your-writes trade. Which one you pick is a per-deployment decision, and it is the first question to ask of any team considering this.

Building the module

The build is a conventional C module build, and the README lists the requirements: build essentials such as a compiler and GNU make, CMake, and the GNU autotools, autoconf, automake and libtool.

The sequence is short:

git clone https://github.com/RedisLabs/redisraft.git
cd redisraft
mkdir build && cd build
cmake ..
make

The output is redisraft.so, created under the project directory, and that shared object is what you load into a Redis server with the --loadmodule option.

The repository layout shows what else is in the tree. There is src for the module sources, deps for the vendored dependencies, docs for the documentation, tests for the test suite, benchmark for performance work, jepsen for Jepsen style consistency testing, utils for helper scripts, and a licenses directory that records the terms of the vendored code.

The jepsen directory deserves a note, because it is the most telling thing in the listing for an evaluator. Jepsen is the approach of running a distributed system under adversarial network partitions and clocks, then checking whether the invariants it claims actually held. For a consensus module, that is the test that matters, and its presence says the project takes the consistency claim seriously enough to test it that way.

Running a three node cluster, starting from the unstable branch

There is a prerequisite that decides whether you can try this at all: RedisRaft requires Redis built from the unstable branch. The README is explicit, and the sequence is:

git clone https://github.com/redis/redis
cd redis
make
make install

That means you are not running a released Redis. You are compiling the development branch, which is a real cost in stability and in effort, and it is the clearest signal of where the project sees itself.

The first node starts with a set of options that are specific to the module: a port, a database filename, the --loadmodule path pointing at redisraft.so, a --raft.log-filename, and a --raft.addr that tells the node its own address.

redis-server \
    --port 5001 --dbfilename raft1.rdb \
    --loadmodule <path-to>/redisraft.so \
    --raft.log-filename raftlog1.db \
    --raft.addr localhost:5001

Then the cluster is initialised, and the remaining nodes are started the same way and told to join:

redis-cli -p 5001 raft.cluster init

redis-cli -p 5002 RAFT.CLUSTER JOIN localhost:5001

The third node repeats that pattern on port 5003, joining the first node rather than the second. The state of the cluster is then readable from any node with the INFO command:

redis-cli -p 5001 INFO raft

The raft.cluster init and RAFT.CLUSTER JOIN commands, the node options and the INFO raft output are the whole visible surface for a first run, and the deeper documentation is in docs/Using.md and the table of contents in docs/TOC.md.

Licence, warning and what the project is not

Two facts should come before any evaluation of the code.

The first is the warning at the top of the README: RedisRaft is still being developed and is not yet ready for any real production use, and the reader is asked not to use it for any mission critical purpose at this time. The README also notes that official updates to the platform can break features, which is a fair warning for anything built on a module.

The second is the licence. RedisRaft is licensed under the Redis Source Available License 2.0, RSALv2, or the Server Side Public License v1, SSPLv1. Neither is an OSI approved open source licence, and both are source-available terms with obligations attached. That is a meaningful difference from a project under MIT or Apache-2.0, and it belongs in an evaluation of a database module before the code, not after it. The licences directory in the repository, and the LICENSE.txt file, are where the terms are recorded.

On the maintenance side, the last push to the default branch was on 2026-04-13, and the repository has no tagged releases. Combined with the warning and the unstable branch requirement, the honest characterisation is a research and development project that is usable for evaluation and experimentation, and that its own authors do not consider ready to carry production traffic.

The comparison with the built-in Redis Cluster is the one to make, and it comes down to where you want the tradeoff. A cluster that partitions the key space and tolerates a partition by staying available on the majority side keeps serving requests during a network event at the price of the strongest consistency guarantees. RedisRaft goes the other way: a replicated log, a single agreed order, and reads that are consistent with that order, at the price of availability on the minority side of a split. Which of those two failure behaviours your system can live with is the real decision, and it is a decision about your workload rather than about the code.

Editorial conclusion

Adopt RedisRaft only if you specifically need a strong-consistency Redis cluster and you are prepared to run pre-release software that the project itself says is not ready for production, on a Redis built from the unstable branch. Do not adopt it for a mission critical deployment, and do not adopt it if the built-in Redis Cluster behaviour meets your consistency needs, because Raft trades availability during a partition for a single consistent log. Before you go further, read the warning at the top of the README, check the licence file, because RSALv2 and SSPLv1 are source-available terms rather than open source ones, and confirm that the last push on 2026-04-13 reflects a project you are prepared to follow.

Frequently asked questions

Official sources

1. Issues
2. README
3. RedisLabs/redisraft on GitHub