Our MariaDB 12.3 LTS webinar is now available as a free PDF download. Over 60 minutes, Shiv Iyer — Founder & CEO of MinervaDB and a database engineer who has spent three decades inside MySQL, MariaDB, and PostgreSQL internals — walks through what the 12.3 LTS generation actually changes in production: the InnoDB-based binary log, parallel replication into Galera, MaxScale failover mechanics, and the mHNSW vector index that turns MariaDB into a credible RAG backend.
This is not a changelog read-aloud. The deck is built the way we run client engagements: every claim tied to a measurement source, every architecture drawn with its RPO/RTO consequences, and a clear statement of where each feature does not apply. Fill in the short form at the bottom of this page and the full deck lands in your inbox.
Here is what the MariaDB 12.3 LTS webinar covers, and why we think the timing matters.
Why the 12.3 LTS generation matters right now
MariaDB 10.6 LTS reached end of life in July 2026. If you are still running it, you are now accumulating unpatched CVEs on your primary OLTP tier — that alone justifies an hour with the MariaDB 12.3 LTS webinar material. The practical question for most estates is no longer whether to move, but whether to land on 11.8 LTS or 12.3 LTS.
The support windows are not symmetrical, and this catches people out. MariaDB 12.3 LTS, released Q2 2026, is maintained through 2029 on a three-year window. 11.8 LTS runs to mid-2030 — a longer runway than the newer release. The webinar opens with this decision: which workloads justify the 12.3 feature set, and which are better served by parking on 11.8 until the next LTS cycle. The MariaDB Foundation publishes the current release calendar; the deck maps it onto upgrade sequencing for mixed estates.
MariaDB's release model has also changed shape: rolling GA releases punctuated by LTS milestones (the .3 releases). If your change-management process still assumes the old cadence, part one of the webinar is the correction.
What the MariaDB 12.3 LTS webinar covers
We built the MariaDB 12.3 LTS webinar for architects and DBAs who own upgrade decisions, not for a general audience.
The MariaDB 12.3 LTS webinar runs five parts across 60 minutes:
- The platform in 2026 — release model evolution, LTS support windows, upgrade planning for estates coming off 10.6.
- Performance — the InnoDB-based binary log, optimizer refinements, and how to validate vendor benchmark claims against your own workload.
- Scalability — parallel replication modes, MaxScale routing, storage engine selection, and analytics offload.
- High availability — Galera Cluster in 12.3, the RPO/RTO decision matrix, MaxScale automated failover, backup and point-in-time recovery.
- AI and vector search — mHNSW indexes, hybrid search with Reciprocal Rank Fusion, and RAG architectures that keep embeddings transactionally consistent with source rows.
Performance: one engine, one recovery protocol, one flush discipline
The headline change in the 12.3 generation is the InnoDB-based binary log. MariaDB has collapsed the old dual-log architecture — binlog and InnoDB redo log, each with its own fsync discipline and a two-phase commit stitching them together — into a single recovery protocol owned by InnoDB.
MariaDB reports roughly 4× write throughput on heavy workloads with this change, with crash safety inherited from InnoDB's redo protocol. We treat that number the way we treat every vendor benchmark: as a hypothesis to test. The webinar dedicates a section to validation methodology — replay your own production statement digests on the candidate version, hold sync_binlog and innodb_flush_log_at_trx_commit constant across runs, measure P95/P99 latency rather than throughput alone, and run at production concurrency with the thread pool configured the way you actually deploy it.
The optimizer work in 12.3 is quieter but operationally useful: reverse-ordered scans, loose index scan with DESC keys, and improved virtual-column costing. Two new hints — JOIN_FIXED_ORDER and MAX_EXECUTION_TIME — give you per-statement plan control, and ANALYZE FORMAT=JSON now surfaces actual row counts against estimates, which is the fastest way to catch a misestimation before it becomes a 2 a.m. page. Our standing advice, repeated in the deck: capture your top-N statement digests and plans before the upgrade, replay them in staging, and diff the plans before cutover. If you want the monitoring side of that discipline, we published the 20 MariaDB metrics we track in every engagement.
Scalability: the levers most teams never pull
MariaDB GTID is not MySQL GTID — the domain-server-sequence format is incompatible, which matters for anyone running mixed fleets or mid-migration topologies. From that foundation, the webinar works through the two parallel-apply modes: conservative, which parallelizes within group commit boundaries, and optimistic, which applies speculatively and rolls back on conflict.
The change we consider most significant for DR design: since 12.1, parallel replication works into Galera nodes. Async replicas feeding a DR cluster were previously throttled to single-threaded apply, and lag on that link was a standing RPO risk. That constraint is gone, and the deck shows the resulting cluster-to-cluster DR topology.
Beyond replication, part three covers MaxScale — read/write split, causal reads, transaction replay, and an honest note on its Business Source License terms — plus storage engine selection: InnoDB for OLTP, MyRocks where write amplification and compression dominate, Aria for temp tables, S3 for cold archives, ColumnStore for analytics, and Spider for sharding. If you run MariaDB on Kubernetes or cloud VMs, our guide to tuning MariaDB for cloud and containerized environments pairs well with this section.
High availability: pick your RPO before you pick your topology
Part four opens with the decision matrix we use in architecture reviews: asynchronous replication gives you seconds of RPO and seconds-to-minutes of RTO; semi-sync closes RPO to approximately zero at a latency cost; Galera gives you zero RPO within the cluster and seconds of RTO, in exchange for three-node quorum, primary keys on every InnoDB table, and a network you can trust.
One trade-off in 12.3 deserves more attention than it has received: the InnoDB-based binary log and Galera are mutually exclusive. wsrep cannot intercept the atomic commit path, so cluster nodes keep the legacy binlog — meaning the 4× write-path improvement and Galera's synchronous replication cannot be combined on the same node. The webinar treats this as a first-class design input, not a footnote. We covered the surrounding architecture decisions in MariaDB high availability in 12.3 LTS and in our piece on building fault-tolerant MariaDB infrastructure at internet scale.
The section closes on operations: MaxScale automated failover via mariadbmon, switchover for planned maintenance, hot physical backups with mariabackup (full plus incremental, with the --prepare step), and point-in-time recovery by replaying the binlog to a target GTID. Two cautions from the deck worth repeating here. First: verify that your mariabackup version and any CDC tooling that reads binlog files directly are certified for the new binlog format before you enable it. Second: an untested backup is a hypothesis, not a recovery plan — measure your verified restore time, and rehearse failover quarterly.
The AI-native database: mHNSW, hybrid search, and honest boundaries
MariaDB now ships a native VECTOR column type with an mHNSW index — a modified HNSW graph — and distance functions for both Euclidean and cosine metrics. The 12.3 generation pushes distance computation down into the storage layer and adds extrapolation-based graph pruning; the practical tuning lever is M, the graph connectivity parameter, which trades recall against memory and latency. A retrieval query stays plain SQL:
SELECT doc_id,
VEC_DISTANCE_COSINE(embedding, @query_vec) AS distance
FROM knowledge_chunks
ORDER BY distance
LIMIT 10;
The webinar's RAG argument is transactional rather than fashionable: embeddings and their source rows commit in one transaction, which eliminates the synchronization drift you accept the moment you bolt a separate vector store onto your OLTP database. Hybrid search fuses keyword and vector results with Reciprocal Rank Fusion, and the deck walks the full architecture. For the index internals, see our earlier post on how vector indexes work in MariaDB and the MariaDB Vector documentation.
And the boundary, stated plainly because vendor decks rarely do: MariaDB Vector is credible up to tens of millions of vectors. At billions-scale, or where GPU-accelerated indexing dominates the workload, a dedicated vector platform is the right call. We say this as a vendor-neutral consultancy — right-size first.
Two reference architectures you can lift directly
The MariaDB 12.3 LTS webinar deck closes its infrastructure arc with two worked topologies. The performance-first design: a 12.3 primary on the InnoDB binlog, two replicas on parallel apply, a delayed replica as a fat-finger safety net, and scheduled backups — seconds of RPO, sub-minute RTO. The availability-first design: a three-node Galera cluster on the legacy binlog with single-writer routing through MaxScale, feeding an async DR cluster that uses the 12.1+ parallel-apply capability. Both diagrams carry version labels and the reasoning for each choice.
Download the MariaDB 12.3 LTS webinar deck (free)
Fill in the form below to get the MariaDB 12.3 LTS webinar PDF — we'll show the download link immediately and email you a copy. We'll occasionally send you technical material like this; no spam, and never a sales sequence you didn't ask for. The MariaDB 12.3 LTS webinar PDF is free, and the download link arrives instantly.
Planning a MariaDB 12.3 upgrade? Talk to us
MinervaDB runs MariaDB in production for enterprises worldwide — consulting, 24×7 support, and remote DBA across the full lifecycle. If the MariaDB 12.3 LTS webinar leaves you with questions — a 10.6 exit plan, a Galera design, a MariaDB Vector evaluation — and you would benefit from engineers who do this every week, contact us. We'll tell you honestly if 11.8 is the better landing zone for your workload — and, as always, test everything in staging before it touches production, and keep your DR posture rehearsed.
