--- title: "MariaDB Raft Cluster: Consistency Without Waiting on Your Slowest Node" publish_date: 2026-11-11 author: "Ralf Gebhardt" --- # MariaDB Raft Cluster: Consistency Without Waiting on Your Slowest Node Table of contents 1. [The problem with "everyone has to agree"](#the-problem-with-everyone-has-to-agree) 2. [How Raft Cluster works](#how-raft-cluster-works) 3. [Flow control: the other half of the story](#flow-control-the-other-half-of-the-story) 4. [What this means operationally](#what-this-means-operationally) 5. [What we're seeing in internal testing](#what-were-seeing-in-internal-testing) ## Key takeaways - Majority-Based Consensus: MariaDB Raft Cluster requires only a majority quorum to commit writes, eliminating latency bottlenecks caused by single slow or distant nodes. - Graceful Throttling over Hard Pauses: When a node falls behind, Raft Cluster throttles overall cluster throughput to a configurable rate instead of completely pausing write operations. - Significant Performance Advantages: Internal cloud benchmarks demonstrate up to 17x higher write throughput in asymmetric latency environments and 47.5% higher throughput on larger 7-node clusters compared to Galera. - Seamless Operations & Integration: Ships as part of MariaDB Enterprise Server 12.3, preserving existing operational workflows, port definitions, snapshot transfer methods, and automatic MaxScale leader routing. 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. ![How Raft Cluster Works](/wp-content/uploads/2026/11/HowRaftClusterWorks.png)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. ![Galera vs Raft Write Throughput](/wp-content/uploads/2026/11/ThrottleRate.png)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: - Questions or feedback? Reach out to your MariaDB account team, or contact us directly: ## Frequently Asked Questions ### Does Raft Cluster replace Galera Cluster? No — it runs as an additional clustering option alongside Galera. You choose the provider per cluster (wsrep\_provider=raft instead of the Galera provider), and the two cannot be mixed within a single cluster. ### Do I need MariaDB MaxScale to use it? No. MaxScale’s Galera Monitor (25.10.2+) detects a Raft Cluster automatically and routes writes to the Leader, but it isn’t required — a write sent to a Follower is simply forwarded to the Leader, at the cost of one extra hop. ### What happens if the Leader fails? The Followers hold a new leader election automatically; no manual intervention is required. ### How does flow control differ from Galera’s? Galera pauses the entire cluster once a lagging node crosses a threshold (gcs.fc\_limit). Raft Cluster throttles instead — the Leader slows the cluster to a steady, reduced write rate governed by raft\_flow\_control\_drift\_limit, and both the drift limit and the throttled rate are configurable. ### Can I mix Raft and Galera nodes in the same cluster? No — a cluster runs with one provider or the other, not both. ### Is Raft Cluster available to everyone running MariaDB? It ships as part of MariaDB Enterprise Server 12.3, and requires an active MariaDB Enterprise Platform Plus subscription. ### Where can I learn more or get a cluster running? See the Quickstart Guide linked above, or reach out via the contact details in the Try it section.