MariaDB Raft Cluster: Consistency Without Waiting on Your Slowest Node

Every clustered database has to answer the same question: how do you keep every node in agreement without letting your slowest node set the pace for everyone else? MariaDB Galera Cluster answers it one way — every node acknowledges every write. MariaDB Raft Cluster, now generally available as part of MariaDB Enterprise Server 12.3, answers it differently: a write commits once a majority of nodes have it, and the cluster throttles down instead of stopping outright when a node falls behind.

The problem with “everyone has to agree”

Galera’s virtually synchronous replication is a genuine strength — it gives you strong consistency with a straightforward operational model, and for tightly coupled clusters with low, uniform latency between nodes, it’s hard to beat. But that same design has a sharp edge: if any one node is struggling — a network blip, a noisy neighbor on shared infrastructure, a disk that’s momentarily slower than usual — every write across the entire cluster has to wait for it. One slow node becomes everyone’s problem.

That’s not a hypothetical edge case. It’s the normal cost of doing business in any environment where low, uniform latency between nodes isn’t guaranteed — which, increasingly, is most environments.

How Raft Cluster works

Raft Cluster is built on the Raft consensus protocol, running as an additional clustering option alongside Galera rather than replacing it — you choose the provider per cluster (wsrep_provider=raft instead of the Galera provider).

The mechanics are deliberately simple:

1. Leader election. One node is elected Leader. All writes go through it.
2. Log replication. The Leader appends each write to its log and replicates the entry to every Follower.
3. Majority commit. The write is considered committed as soon as a majority of nodes — including the Leader — have durably stored it. In a 7-node cluster, that’s 4 nodes, not 7.
4. Automatic failover. If the Leader stops responding, the Followers elect a new one without manual intervention.

Because commit no longer depends on every node, the round-trip time to your most distant or momentarily slow node stops dictating the latency of every write.

Flow control: the other half of the story

Majority commit solves the commit problem, but it doesn’t make a lagging node’s existence disappear — something still has to happen when a node falls meaningfully behind on applying the replicated log. This is where Raft Cluster’s flow control differs most clearly from Galera’s.

Galera’s flow control is a hard stop: once a lagging node’s queue passes a threshold (gcs.fc_limit), replication pauses across the whole cluster until it catches up — potentially more than once during a single slow period.

Raft Cluster’s flow control throttles instead. The Leader tracks how far each node has fallen behind and slows the cluster to a steady, reduced write rate — it never stops writes outright, and the lagging node’s own writes still go through. That rate is governed by raft_flow_control_drift_limit (default 100), and importantly, both the drift limit and the throttled rate itself are configurable — you can tune how much headroom the cluster has before throttling engages, and how much it costs you when it does.

One detail worth understanding: throttling isn’t purely a function of latency. It’s closer to a bandwidth-delay product — roughly, drift accumulates as transaction rate × node lag. At 1,000 TPS, a cluster might not throttle until a node falls about 100ms behind; at 2,000 TPS, the same drift limit is reached around 50ms of lag. A busy cluster has less headroom before a given amount of lag becomes a problem than a quiet one does — which is exactly why this isn’t simply “Raft for high-latency networks.” It’s Raft for any cluster where latency between nodes isn’t perfectly predictable, which may matter more as transaction volume grows, not less.

What this means operationally

Raft Cluster deploys and operates close to how Galera already does, deliberately:

• It ships as part of MariaDB Enterprise Server 12.3 — one additional package (mariadb-raft) alongside the server you already run.
• Most wsrep_* system and status variables carry over unchanged; a handful of Raft-specific variables (raft_*) sit alongside them.
• Client connections are unaffected (port 3306). Raft traffic and internal replication consolidate onto a single port (50002), with a separate port for snapshot transfer requests (50001) — using the same snapshot transfer methods (mariadb-backup, rsync, mariadb-dump) Galera already uses.
• Bootstrapping follows the same two-step pattern as Galera, with a different command (mariadb-new-cluster in place of galera_new_cluster).
• A small number of settings don’t carry over as-is — wsrep_provider_options and wsrep_ssl_mode are superseded by Raft-specific equivalents.
• MariaDB MaxScale’s Galera Monitor (25.10.2+) automatically detects a Raft Cluster and routes writes directly to the Leader via the existing ReadWriteSplit router, without additional configuration. It still works without MaxScale too — a write sent to a Follower is simply forwarded to the Leader, at the cost of one extra hop.

What we’re seeing in internal testing

In a companion post, Benchmarking MariaDB Raft Cluster vs. MariaDB Galera Cluster, Axel Schwenke compares the two head to head on Google Cloud. He tests the two situations where the difference between majority commit and every-node commit should show up: one node with higher network latency, and clusters with more than three nodes. The post covers the full test setup, the sysbench workloads and every result.

The short version:

• One slow node: with one node of a 3-node cluster at 80 ms round-trip time, Raft Cluster sustained about 2,150 TPS writing to the leader. Galera Cluster sustained about 125 TPS, about 17 times less.
• More nodes: on a write-only workload with 7 nodes, Raft Cluster reached 9,714 peak TPS on the leader against 6,587 TPS for Galera Cluster, 47.5% more.
• Uniform low latency: on a 3-node cluster the results were close. Galera Cluster was about 2% faster with no added latency and up to 4.9% faster on some other workloads, while Raft Cluster was 11.2% faster on a write-only workload when writing to the leader.

These are internal results rather than published, independently reproducible benchmarks, and we’d encourage anyone evaluating Raft Cluster to validate against their own workload and topology.

Try it

MariaDB Raft Cluster is generally available today as part of MariaDB Enterprise Server 12.3, and ships as part of MariaDB Enterprise Platform 2027. Access requires an active MariaDB Enterprise Platform Plus subscription.

• Follow the Quickstart Guide to stand up a 3-node cluster in a lab or VM environment: https://mariadb.com/docs/release-notes/advanced-cluster/mariadb-advanced-cluster-quickstart-guide
• Questions or feedback? Reach out to your MariaDB account team, or contact us directly: https://mariadb.com/contact/

Frequently Asked Questions