Key takeaways
- Conflict Detection and Resolution (CD&R): Introduces built-in support for multi-writer, active-active replication, using SQL triggers to detect and resolve conflicts.
- Raft Cluster: Adds a Raft-based high-availability option that commits a write once a majority of nodes have it, for lower write latency across regions and automatic failover.
- Higher Performance & Scalability: Delivers approximately 25% higher throughput than MySQL 9.7.2 (peaking at 2.65 million NOPM), augmented by InnoDB-based binary logging (up to 50% throughput increase) and faster vector searches.
- Streamlined Security: Features passwordless TLS certificate authentication, HashiCorp Vault key rotation without server restarts, SHA-2 and PBKDF2 data-at-rest encryption enhancements, and automated TLS private key passphrases for unattended restarts.
- Broadened Migration Compatibility: Expands support for MySQL features (caching_sha2_password, optimizer hints, GIS functions) and Oracle elements (SQL syntax, datatypes, PL/SQL stored procedures, and multi-event triggers) to reduce application changes.
What is MariaDB Enterprise Server?
MariaDB Enterprise Server is a core component of our flagship product MariaDB Enterprise Platform, delivering a hardened, production-grade edition of MariaDB Community Server. MariaDB Enterprise Server is enhanced with specific features that meet enterprise requirements such as advanced audit logging, non-blocking backup support, and data-at-rest encryption, along with backported fixes and professional support agreements.
Read on for what’s new and what it means for your MariaDB Enterprise Platform deployments.
Conflict Detection and Resolution
If you run multi-writer, active-active replication, you need a way to handle conflicting writes across nodes and keep your data consistent. MariaDB Enterprise Server 12.3 introduces Conflict Detection and Resolution (CD&R), which lets you resolve conflicts in SQL with triggers that apply rules tailored to your business needs.
When multiple servers accept writes, each can update its local copy of the same row before receiving changes from the others. For example, Customer 101’s phone number starts as 333 on both servers, then is updated to 111 on one server and 222 on another. Conflicts can also arise when an operator or application changes data directly on a replica. Without conflict handling, these differences can lead to replication interruptions, overwritten updates and manual data recovery.
Figure 1: Conflicting updates to the same customer record
How does CD&R resolve conflicting writes?
CD&R detects conflicts as replicated changes reach a replica and invokes a SQL trigger containing your resolution rules. For the phone-number example, the rules determine which value to retain. When changes affect different fields, a trigger can merge them to preserve both updates, such as keeping an operator’s email correction while still applying a replicated phone-number change. In active-active deployments, your rules must consistently bring participating nodes to the same result.
Figure 2: Consistent customer data after conflict resolution
CD&R detects five types of conflict: INSERT_INSERT, UPDATE_UPDATE, DELETE_UPDATE, UPDATE_DELETE, and DELETE_DELETE. For each, a trigger can assign a new row, apply the default result, skip the event, or halt replication so an operator can investigate. For details, see the CD&R triggers documentation.
CD&R works with standard asynchronous and semisynchronous replication, supporting a range of topologies, including primary–replica, multi-source, bidirectional, ring, mesh and star. It does not apply to Galera Cluster, which uses certification to detect conflicting transactions, or Raft-based clusters, where a single leader accepts writes.
Raft Cluster
MariaDB Raft Cluster is a new clustering option in MariaDB Enterprise Server 12.3, offering an alternative to Galera Cluster. Its replication layer is built on the Raft consensus protocol and uses a leader-follower architecture: one node acts as the leader and coordinates writes, and a write commits once a majority of nodes have it, so a slow or distant node no longer sets the commit latency for the whole cluster. If the leader fails, the followers elect a new one automatically, without manual intervention.
Raft Cluster also introduces a new flow control system that does not block the cluster. When a node falls behind, the cluster throttles to a reduced write rate instead of pausing replication, so writes keep going while the lagging node catches up.
To learn more about how MariaDB Raft Cluster and the new flow control work, see Raft QuickStart Guide.
Figure 3: Raft Cluster commits a write once a majority of nodes has it
Performance
MariaDB Enterprise Server 12.3 helps you process more transactions on your existing hardware, improving price-performance and giving you more capacity to support growing workloads before expanding your infrastructure.
How much faster is MariaDB Enterprise Server 12.3 than MySQL 9.7.2?
In a benchmark by McKnight Consulting Group, MariaDB Enterprise Server 12.3.3 delivered about 25% higher throughput than MySQL 9.7.2 at equal concurrency across 64 to 120 virtual users. Throughput continued to scale to 152 virtual users, reaching 2.65 million new-order transactions per minute.
By comparison, throughput for MariaDB Enterprise Server 11.8.3-1 peaked at 88 virtual users before declining. If you’re staying on the 11.8 release series, you can benefit too: MariaDB Enterprise Server 11.8.9 delivers performance comparable to 12.3.
Figure 4: Throughput scaling by virtual users
What other performance improvements are included?
InnoDB-based binary logging
If you run write-intensive applications, you can process more transactions with less logging overhead. InnoDB-based binary logging integrates binary log writes with InnoDB’s write-ahead log, reducing the disk synchronisation required when committing transactions.
MariaDB Server 12.3 with InnoDB-based binary logging delivered up to 50% higher throughput than MariaDB 11.8.8 with traditional binary logging. See how InnoDB-based binary logging improves transaction throughput, and InnoDB-based binary log documentation.
Faster vector search
MariaDB Vector in 12.3 skips unnecessary full-vector comparisons, which reduces the work each search performs. On the dbpedia-openai-1000k benchmark, it delivered up to 30% more queries per second than MariaDB 11.8 at the same recall. The optimisation applies automatically, without changes to your schema, indexes or queries. See how MariaDB Server 12.3 accelerates vector search.
Security
MariaDB Enterprise Server 12.3 helps you spend less time managing passwords, strengthen protection of cryptographic keys, and simplify key rotation and unattended restarts.
What is passwordless authentication using TLS certificates?
The new tls_certificate authentication plugin lets accounts authenticate using trusted TLS client certificates without an additional database password, reducing password administration. Previously, certificate validation had to be paired with a second authentication method, typically a password.
The plugin is built in and enabled by default, and existing clients and connectors need no change. See passwordless authentication with TLS certificates.
How can you rotate HashiCorp Vault keys without restarting?
You can rotate encryption keys in HashiCorp Vault and make them available to the server without a restart, avoiding planned downtime, dropped connections and cold caches.
Running FLUSH HASHICORP_KEY_MANAGEMENT_CACHE clears the plugin’s key cache while the server remains running, allowing MariaDB to retrieve newly rotated key versions from Vault. Previously, this required a server restart. You can now schedule regular key rotation without a database maintenance window. See HashiCorp Key Management documentation.
How do SHA-2 and PBKDF2 strengthen protection of TDE key files?
MariaDB Enterprise Server 12.3 adds SHA-2 digests, including SHA-256 and SHA-512, and optional PBKDF2 for deriving the key used to encrypt your TDE key file. SHA-2 support lets you move away from SHA-1 to NIST-approved hash algorithms.
PBKDF2 adds a second layer of protection. It repeats the key derivation many times, so every password guess an attacker tries against a copied key file costs far more computing work. It works with either SHA-1 or SHA-2. See File Key Management encryption.
How do passphrase-protected TLS private keys support unattended restarts?
You can keep your TLS server private key protected by a passphrase while supporting unattended startup and automated recovery. MariaDB Enterprise Server 12.3 can obtain the passphrase for a protected TLS private key automatically, from a file, an environment variable, or a literal value, through the ssl_passphrase system variable.
Previously, an interactive passphrase prompt could block startup until an operator intervened. Access to both the private key and its passphrase source must remain restricted. See configuring passphrases for TLS private keys.
MySQL and Oracle Compatibility
MariaDB Enterprise Server 12.3 helps you reduce application changes and migration effort through expanded MySQL and Oracle compatibility.
What makes migrating from MySQL easier?
MySQL password authentication
You can migrate your MySQL accounts without password resets for your users and applications. Support for caching_sha2_password lets you migrate MySQL account authentication strings while retaining existing password hashes. See caching_sha2_password plugin.
MySQL-style optimizer hints
Expanded support for MySQL 8-style optimizer hints lets you retain more query-level tuning instructions and control individual execution plans without changing server-wide settings. See optimizer hints.
MySQL-compatible GIS functions
You can reduce spatial-query rewrites when migrating mapping, logistics and location-based applications. Additional spatial functions support GeoHash conversion, geometry validation, shape simplification and spatial operations. See ST_GeoHash as an example.
What makes migrating from Oracle easier?
Oracle SQL syntax, data types and functions
You can reuse more existing queries and schema definitions. Oracle-style outer joins using (+), the IS JSON predicate and the XMLTYPE data type reduce migration changes. Functions such as TO_DATE, TO_NUMBER, TRUNC and MONTHS_BETWEEN support familiar date and number processing. See Oracle compatibility.
PL/SQL compatible stored procedures
You can preserve more stored-procedure logic with associative arrays, SYS_REFCURSOR and dynamic SQL cursors, including collections, procedures that return query results and queries constructed at runtime. See associative arrays.
Trigger and execution-context changes
You can migrate triggers and routines with less rework.Multi-event triggers allow one trigger to handle inserts, updates and deletes. SET PATH controls schema searches for routines, while SET SESSION AUTHORIZATION allows authorised connections to switch execution identity. See multi-event triggers and SET PATH.
How do I get MariaDB Enterprise Server 12.3?
MariaDB Enterprise Server 12.3 is available now to MariaDB Enterprise Platform customers. Review the release notes for upgrade guidance, or contact us to talk through which new features fit your environment.
Frequently Asked Questions
You need to define SQL triggers containing your resolution rules. MariaDB detects supported replication conflicts and invokes the appropriate trigger. It does not decide which value is correct for your business.
No. Galera Cluster uses certification to detect conflicting transactions, and in Raft-based clusters a single leader accepts writes, so there are no write conflicts to resolve. CD&R works with standard asynchronous and semi-synchronous replication, including multi-source, bidirectional, ring, mesh, and star topologies.
No. Flushing the cache makes MariaDB retrieve keys again from Vault on subsequent access. Re-encrypting existing data is a separate operation, and older key versions must remain available while data still depends on them.
Yes. Authentication is configured per account, so certificate-authenticated accounts can coexist with accounts using password authentication. You can adopt certificate authentication gradually.
No. These options affect how the key protecting your encrypted TDE key file is derived. Your tables continue to use AES encryption, and existing settings remain unchanged unless you configure the new options.
