OpenRaft: A Rust Raft Implementation That Redesigns Voting and Membership Changes

What OpenRaft Solves for Distributed Storage Builders

OpenRaft targets developers building distributed data systems: SQL, NoSQL, KV, streaming, graph, or something more exotic. Standard Raft implementations often force one-node-at-a-time membership changes and suffer from election conflicts that waste terms. OpenRaft addresses both. The README states it is the consensus engine of the meta-service cluster in Databend, so it is not a toy. The project derives from async-raft but fixes several bugs, as documented in derived-from-async-raft.md. If you need a Raft library that lets you change an arbitrary set of nodes in one operation and reduce split-vote churn, OpenRaft is built for that specific gap.

How the Vote Redesign Reduces Election Conflicts

Standard Raft increments the term on every election, and a split vote forces a new term, causing repeated conflicts. OpenRaft introduces a redesigned Vote that minimizes the conflict rate. According to the roadmap, a split vote does not force a new term. The design is documented in the Vote data type and the LeaderId data type. The README mentions two modes: the new leader-ID mode and the standard Raft leader-ID mode. This is a concrete mechanism, not a vague claim. The practical effect is fewer term increments under contention, which should reduce log disruptions. The documentation does not give a formal proof, but the design discussion link suggests the reasoning is public.

Extended Joint Membership for Arbitrary Node Changes

Standard Raft changes membership one node at a time, which is slow and restrictive. OpenRaft implements extended joint membership, allowing an arbitrary set of nodes to be changed in a single operation. The README calls standard Raft's approach a restricted special case. This matters for operators who need to replace multiple nodes at once, for example during a datacenter migration. The implementation is in the ExtendedMembership data type. The trade-off is complexity: joint consensus is harder to reason about than simple majorities. OpenRaft's deterministic simulation fuzzer and Jepsen suite are designed to catch the subtle bugs that arise from this complexity.

Getting Started: Commands and Configuration

OpenRaft is a Rust crate, so you add it via Cargo. The README points to the getting started guide at docs.rs/openraft/0.10.0-alpha.34/openraft/docs/getting_started/index.html. The examples for version 0.10 live in the release-0.10 branch and require openraft 0.10.0-alpha.34. For version 0.9, examples are in the release-0.9 branch. The main configuration key mentioned is Config::enable_pre_vote, a boolean that enables the pre-vote feature. Pre-vote lets a node ask peers whether they would grant a vote before incrementing its term. The README does not list a full config file, so you must consult the guide for the complete set of fields. The alpha version number means you should pin the exact version in Cargo.toml.

Performance Numbers: What They Do and Do Not Mean

The README reports 33,000 writes per second for a single writer and up to 5,615,000 writes per second with batch writes. It explicitly warns that these benchmarks run on a minimized store and network, and are NOT a real world application benchmark. That warning is important. The numbers measure the framework's overhead, not the throughput you will get with a real disk and network. The benchmark folder benchmarks/minimal contains the details. Treat these figures as an upper bound for the consensus layer alone. If you need a realistic estimate, you must benchmark with your own storage backend and network conditions.

Testing and Chaos Verification

OpenRaft claims 92% unit test coverage. More importantly, it runs a deterministic simulation fuzzer in tests-turmoil on every CI build. This fuzzer explores interleavings deterministically, which is far more effective than random testing for consensus bugs. The Jepsen suite runs eight nemesis scenarios on every push to main: network partition, process pause, process kill, slow packets, flaky packets, clock skew, membership churn, and all combined. This is a serious investment in correctness. The trade-off is that the test infrastructure is complex to adapt to your own application. The fuzzer is tied to the library's internals, so you cannot directly reuse it for your custom logic.

API Stability and Upgrade Costs

The README is blunt: the OpenRaft API is not stable yet. Before 1.0.0, an upgrade may contain incompatible changes. The change-log uses commit prefixes to signal severity: data-change means on-disk data types change and may require manual upgrade, change means incompatible API changes, feat is compatible, fix is a bug fix. The 0.10 line is alpha, and the 0.9 line only accepts bug fixes. This means you must budget for migration work between versions. The project provides upgrade guides, for example from 0.9 to 0.10. If you cannot tolerate breaking changes, wait for a stable release or pin to a specific version and treat upgrades as separate projects.

A Real Alternative: async-raft and Standard Raft

OpenRaft is derived from async-raft, so that is the most direct alternative. The difference is that OpenRaft fixes bugs in async-raft and adds features like extended joint membership and the redesigned Vote. Standard Raft, as implemented in other libraries, uses one-node-at-a-time membership changes and the original leader-ID mode. If you need strict adherence to the original Raft paper for certification or simplicity, standard Raft is safer. If you need arbitrary membership changes and reduced election conflicts, OpenRaft offers a concrete advantage. The cost is a less stable API and a more complex implementation. Choose based on whether you need the extensions, not on star counts.

Editorial conclusion

Adopt OpenRaft if you are building a distributed storage system in Rust and need a consensus engine that goes beyond standard Raft, especially for arbitrary membership changes and reduced election conflicts. Do not use it if you require a stable API before 1.0.0; the 0.10 line is alpha and may break compatibility. Before adopting, verify the current change-log for data-change commits, review the 0.9 to 0.10 upgrade guide, and run the deterministic simulation fuzzer against your own configuration. The project is production-used in Databend's meta-service, but the API instability means you must budget for migration work.

Official sources

1. Official README
2. Project repository
3. Release notes