Enterprise Cluster
MariaDB Enterprise Cluster on Cloud uses synchronous replication with write-set certification and single-writer routing via MaxScale for zero-data-loss failover.
Enterprise Cluster allows you to run highly available database deployments using a synchronous architecture instead of relying on standard asynchronous replication. While the underlying technology supports multi-primary writes, MariaDB MaxScale is configured to route all write traffic to a single active writer node to ensure maximum stability.
MariaDB Cloud typically uses an asynchronous primary/replica model, which provides excellent scalability and read performance for most workloads. However, you might need a different configuration if your business or application requires strict data consistency and zero data loss failover. With Enterprise Clusters, your MariaDB Cloud deployment utilizes synchronous replication, providing strong consistency guarantees while preserving our core value proposition of automation and operational simplicity.
How it works
An Enterprise cluster is a specialized, highly available environment within MariaDB Cloud designed for workloads that cannot tolerate replica lag.
Synchronous replication: Data is replicated synchronously across all nodes using write-set certification, ensuring transactions are committed everywhere simultaneously.
Single-writer routing: MariaDB MaxScale is configured to route all write traffic to a single active writer node at any given time to prevent transaction conflicts. Reads can be load-balanced across the remaining nodes.
Automated failover: If a node fails, MariaDB MaxScale automatically routes traffic to the remaining healthy nodes without customer intervention or data loss.
Quorum management: The cluster automatically maintains a voting system (quorum) to prevent split-brain scenarios and preserve data integrity during network partitions.
Why use Enterprise Cluster
Consider using Enterprise Cluster if you have specific business needs or strict application requirements, such as:
Regulated industries: If you operate in finance, healthcare, or other sectors requiring deterministic behavior during failures and absolute data consistency (RPO 0).
Active-active OLTP systems: If your SaaS platform or legacy enterprise application was architected around multi-primary Enterprise Cluster semantics on-premise and requires a lift-and-shift to the cloud.
Zero tolerance for replica lag: If your application logic fails when reading stale data and requires immediate consistency across all database nodes.
Automated operations: If you want the benefits of a complex synchronous cluster but need the operational burden (patching, upgrades, and failover) abstracted away into a fully managed service.
Who is eligible for Enterprise Cluster
It is a premium deployment topology designed for advanced, mission-critical workloads. You can provision a Enterprise cluster if:
You are subscribed to the PowerPlus tier on MariaDB Cloud.
You are deploying in Amazon Web Services (AWS), Google Cloud, or Microsoft Azure.
When to use the regular Replicated deployment
Enterprise Cluster inherently introduces slight commit latency because all nodes must acknowledge a write before it is finalized. Furthermore, unsafe or highly sensitive Enterprise Cluster configuration variables are strictly system-managed to ensure stability.
In most cases, if your application is highly write-intensive, distributed across large geographic distances, or can tolerate standard asynchronous replication lag, you can meet your performance requirements by utilizing a standard Replicated topology.
If you are unsure whether your workload requires synchronous replication with Enterprise Cluster or standard asynchronous replication, contact our team for a sizing and architecture review.
Enterprise Cluster pricing and billing
Enterprise Cluster follows the standard unit compute, storage, and backup pricing for the PowerPlus tier. This means that databases running either standard Replicated or Enterprise Cluster topologies with a similar node size, count, and storage will incur the same base cost.
Data transfer charges for replication traffic are passed through similarly to other topologies.
Enterprise Cluster architecture
Enterprise Cluster are designed for high availability, fault tolerance, and uniform operational behavior. When deployed, the cluster provisions a set of uniform nodes distributed across your chosen cloud infrastructure. At the edge of the cluster sits MariaDB MaxScale, which acts as the intelligent routing and high-availability layer for your database traffic.
To maximize resiliency, multi-node clusters can be spread across multiple Availability Zones within a single cloud region.
As illustrated above, MaxScale receives read and write connections from your application and can route them to any of the available primary nodes. Because all nodes participate in synchronous replication, data is kept strictly consistent across all availability zones.
If a single node or an entire zone fails, MaxScale immediately redirects traffic to the surviving nodes. As long as a mathematical majority of nodes remain online, the cluster maintains "quorum" and ensures uninterrupted, writable database service without manual intervention.
Enterprise Cluster consists of a minimum of 3 and a maximum of 5 nodes to maintain this quorum. (A single-node cluster option is available strictly for dev/test purposes). When deployed, instances start at 4 vCPU and 16 GB RAM.
Synchronous Replication Write Path
Unlike asynchronous replication where the primary commits first and replicas catch up later, Enterprise Cluster requires certification from the cluster before a transaction is finalized.
Node Failure and Quorum Resolution
Because Enterprise Cluster relies on a mathematical majority to maintain cluster state, it automatically handles node failures without manual intervention or data loss.
If a node goes offline unexpectedly, MariaDB MaxScale detects the failure and immediately stops routing application traffic to it. The remaining active nodes check their voting pool; as long as more than half of the cluster remains online (e.g., 2 out of 3 nodes), the cluster maintains "quorum" and continues accepting reads and writes.
Once the failed node is recovered or replaced by the managed service, it automatically rejoins the cluster, synchronizes its state using a State Snapshot Transfer (SST) or Incremental State Transfer (IST), and resumes accepting traffic from MaxScale.
Configuration and monitoring
MariaDB Cloud exposes a curated, safe subset of wsrep_ variables (such as those controlling flow control and certification) through the Configuration Manager.
For Enterprise Cluster services, the Portal adds cluster-aware monitoring panels alongside the standard service panels:
Flow Control Pause %: the proportion of time replication was paused by flow control.
Flow Control Messages Sent: the rate at which the node sends flow-control messages.
Replication Queue Depth Received: the depth of the local receive queue.
Write Conflicts: the rate of certification failures and brute-force aborts.
Max Galera Replication Latency: the highest observed write-set replication latency, in seconds.
Transactions: the rate of write-sets received and replicated.
Writeset Traffic: the volume of write-set data received and replicated.
A Galera Nodes table reports per-node cluster state:
Instance
The node the row describes
Status
Up or Down
Accept Queries
Ready or Not Ready
Local State
Initialized, Joining, Donor, Joined, Synced, or Inconsistent
Flow Control
ON or OFF
Cluster Status
Disconnected, Primary, or Non-Primary
Connected
ON or OFF
Enterprise Cluster services add four cluster-specific alerts. They are not enabled by default: add them to an alert policy from the Portal, after which they appear in the Alerts view and can be delivered through your configured notification channels:
Galera cluster down
Critical
The cluster is not in the Primary state, or the node is not ready, for 5 minutes.
Galera node not ready
Warning
The node is not in the Synced state for 5 minutes, and the change is not a temporary desync.
Galera node in an unexpected state
Critical
The node's state is not one of Synced, Donor/Desynced, Joining, Joined, or Waiting for SST, for 5 minutes.
Galera donor lagging
Warning
A donor node's receive queue exceeds 100 for 5 minutes, indicating it is falling behind.
Enterprise Cluster service backups
Because Enterprise Cluster uses synchronous replication, backup and restore operations must be cluster-aware to preserve consistency and avoid data divergence.
Snapshots: Enterprise Cluster uses cloud-native snapshot backups. Because Enterprise Cluster ensures write-set consistency, a snapshot from any single healthy node safely represents the entire cluster state.
Point-in-Time Recovery (PITR): You can restore an Enterprise Cluster to a specific point in time between snapshots, in the same way as a Replicated service. See Point-in-Time Restore.
Cluster Restores
To ensure safe re-formation, restores are initialized on a single node to bootstrap the cluster, followed by automated transfers to bring additional nodes online.
Dev tools for Enterprise Cluster
You can manage, provision, and scale your Enterprise Cluster using standard MariaDB Cloud methods, including the MariaDB Cloud Portal and REST APIs.
Enterprise Cluster is presented as a distinct deployment topology alongside Single Node and Replicated topologies, providing a unified management experience.
This page is: Copyright © 2026 MariaDB. All rights reserved.
Last updated
Was this helpful?