Key takeaways
- Significant Performance Gains: MariaDB Enterprise Server 12.3 delivers 56% higher peak throughput than version 11.8 and reduces 99th-percentile response times from 6.54 ms to 3.60 ms on a 192-vCPU Google Cloud instance.
- Superior Efficiency vs. MySQL: Version 12.3 outperforms MySQL 9.7.2 Community by 13% at peak load while consuming only 70% of CPU resources (compared to MySQL's 91%).
- Enhanced Scaling with Raft Cluster: MariaDB Raft Cluster commits writes as soon as a majority of nodes store them, eliminating the bottleneck of waiting for every node in multi-site deployments.
- Automated Multi-Primary Replication: Conflict Detection and Resolution (CD&R) enables fast local writes across multiple regions and automatically resolves write collisions using custom SQL trigger rules.
- Cluster-Wide Query Caching: MaxScale query result caching, now with MariaDB GridGain as a shared storage option, stores and serves repeated expensive queries (like dashboards and reports) across the entire cluster without recomputing them.
Demanding database workloads ask two things of the database underneath them. Each server has to turn the hardware it runs on into as many transactions as possible, and the system has to keep growing once a single server is no longer enough. MariaDB Enterprise Platform 2027 moves forward on both.
In this blog, we’ll walk you through what’s new, starting with raw performance on a single server, then scaling across nodes and sites, and finally caching that takes repeated work off the database.
Faster on every server
Modern servers pack 96 or more cores into a single socket. On hardware that size, the hardware is rarely the limit. The real question is whether the database can put all of those cores to work, because a database that stalls on internal contention leaves expensive capacity sitting idle. For this release, the engineering team went looking for those contention points in the transaction path and removed many of them. The result is MariaDB Enterprise Server 12.3, which keeps scaling well past the point where earlier versions leveled off.
To measure the difference, McKnight Consulting Group ran a TPC-C-derived benchmark, commissioned by MariaDB, on a 192-vCPU Google Cloud instance. Enterprise Server 12.3 delivered 56 percent more peak throughput than Enterprise Server 11.8. The older release peaked at 88 concurrent users with 60 percent of its CPU still idle, and adding more users only slowed it down. Version 12.3 kept climbing until 152 users and handled 34 to 63 percent more transactions at every load level from 88 to 152 users. Each transaction got faster too. At each version’s peak, the 99th-percentile response time for new orders fell from 6.54 ms to 3.60 ms, even though 12.3 was processing 56 percent more orders.
The same test compared 12.3 with MySQL 9.7.2 Community. MariaDB came out 13 percent ahead at each database’s peak, and 21 to 26 percent ahead at every load level from 64 to 152 users. It got there using 70 percent of the CPU, while MySQL needed 91 percent to reach its lower peak. All three databases ran on the same instance at the same hourly cost, so more throughput also means more transactions for every dollar spent on infrastructure. The tests ran fully in memory to isolate how each database engine scales, and the report lists every configuration setting so the results can be reproduced. There is nothing to switch on and nothing to rewrite: you upgrade, and the same hardware serves more users.
Scaling beyond a single server
Getting more out of each server is one kind of scale. When one server is no longer enough, many teams move to a cluster, and running one across several sites has always meant a hard trade-off. Galera Cluster keeps every node holding an identical, up-to-the-moment copy of the data, which works well when the nodes sit close together on a fast, steady network. Spread them farther apart, or onto a network where latency comes and goes, and it slows down. Every write has to be acknowledged by every node before it commits, so the whole cluster moves at the speed of its slowest node.
MariaDB Raft Cluster, now generally available, is built for that situation. It runs in the same Enterprise Server as Galera Cluster with a different consensus engine underneath, so it sits alongside Galera Cluster rather than replacing it. Instead of waiting for every node, Raft commits a write as soon as a majority of nodes have stored it, so one slow or distant node does not hold up every commit. It also handles a node that falls behind differently. In Galera Cluster, flow control lets a lagging node pause writes across the whole cluster until it catches up. In Raft Cluster, the leader slows writes to a steady rate you set instead of stopping them, and only when the cluster is under both heavy load and high lag. If the leader goes down, the remaining nodes elect a new one automatically. Spread three nodes across three data centers, and the cluster keeps committing writes even if one of them goes offline.
Some applications need something different: fast local writes in every region, not just one region. That calls for a multi-primary setup, where each region has its own writable primary and changes replicate between them. The risk is a collision, where the same record gets changed two different ways in two regions before they have synced. Sorting that out used to mean stopping replication and having someone fix it by hand. Conflict Detection and Resolution (CD&R) handles it for you. MariaDB detects the conflict, settles it using rules you define in a SQL trigger, and keeps replication running without anyone getting paged. If you need one consistent write path with automatic failover, Raft Cluster is the fit. If every region needs to write locally and you can handle the occasional conflict, CD&R is.
Taking repeated work off the database
A lot of the load on a busy database is the same work done again and again. When the same expensive query runs over and over, say a report that several services all pull, most setups recompute it every time, which is wasted work. MaxScale query result caching takes care of that. MaxScale is MariaDB’s intelligent proxy, sitting between your applications and your database servers, and its query result cache now has a new storage option with MariaDB GridGain. With MariaDB GridGain behind it, the whole cluster shares one cache instead of keeping a separate one on each node. The query runs once, and after that the stored answer comes straight back from the cache, freeing up database capacity that was being spent recomputing the same result.
The same capability is coming to MariaDB Cloud as a Public Preview on the Power and Power Plus tiers. You switch it on with a single setting when you launch a database, or add it later, and MaxScale starts answering repeated queries from a MariaDB GridGain cache node. Expensive reads like dashboards and reports come back from the cache instead of hitting the database every time. For now it works with databases using semi-synchronous replication, not with Galera Cluster or serverless.
Where to go next
If you are an architect or DBA, start with the full McKnight Consulting Group benchmark report for the test setup and configurations, then read the release documentation and try the pieces that fit your workload. If you are planning an upgrade from MariaDB 11.8 or a move from MySQL, talk to our team about what these results could mean for your environment. Either way, MariaDB Enterprise Platform 2027 is built for your most demanding workloads.
Frequently Asked Questions
Enterprise Server 12.3 delivers 56% more peak throughput than version 11.8, scales up to 152 concurrent users on a 192-vCPU Google Cloud instance, and improves 99th-percentile new-order response times to 3.60 ms.
Unlike Galera Cluster, which requires synchronous acknowledgments from every node and is constrained by network latency, Raft Cluster commits writes as soon as a majority of nodes acknowledge them, ensuring continuous operation even if one data center goes offline.
CD&R is a feature designed for multi-primary architectures that allows local writes across multiple regions. If the same record is modified concurrently in different regions, MariaDB automatically detects the conflict and resolves it using rules defined in a SQL trigger.
MaxScale acts as an intelligent proxy between applications and database servers. When its query cache is backed by MariaDB GridGain,the entire cluster shares a single cache, so repeated expensive reads come straight from the cache without hitting the database engine.
