MariaDB 13.0 is stable, with UPDATE RETURNING, InnoDB log archiving, improved Optimizer Trace, and further SQL compatibility work.

UPDATE RETURNING

Small syntax, meaningful consequence.

UPDATE orders
SET status = 'shipped', shipped_at = NOW()
WHERE status = 'pending' AND warehouse_id = 3
RETURNING id, customer_id, shipped_at;

Without it, updating rows and then needing to know which rows you updated requires either selecting first, which races with other writers, or updating and then selecting, which races just as badly. The usual workaround is a transaction with a SELECT ... FOR UPDATE, which holds locks longer than necessary.

RETURNING does both in one statement, atomically, with the lock held only as long as the update takes. PostgreSQL has had this for years and it is one of the things people miss when moving the other way.

InnoDB log archiving

The more operationally significant feature.

InnoDB writes to a redo log that is a fixed-size circular buffer: once it wraps, the old contents are gone. That is fine for crash recovery, which only needs the recent past, and it is why point-in-time recovery on MySQL and MariaDB has traditionally depended on the binary log instead.

Log archiving preserves redo log contents beyond the wrap, which gives a second path to point-in-time recovery working at the InnoDB level rather than the replication level.

For anyone running backups, this widens the options. A physical backup plus archived logs can roll forward to a chosen moment, which is closer to how PostgreSQL’s WAL archiving works and a model many people find easier to reason about. Our backup guide covers the surrounding discipline, and the point about testing restores applies to databases more than anywhere else.

Optimizer Trace

Improved, and underused.

When a query is slow and EXPLAIN shows a plan you disagree with, Optimizer Trace shows why the optimiser chose it: which plans it considered, what it estimated each would cost, and where your expected plan was rejected.

SET optimizer_trace = 'enabled=on';
SELECT ...;
SELECT * FROM information_schema.OPTIMIZER_TRACE;

The output is verbose JSON and it answers questions EXPLAIN cannot, usually revealing that a cardinality estimate is badly wrong and statistics need updating.

MariaDB against MySQL

The fork is far enough along that “drop-in replacement” no longer holds. The wire protocol is compatible and the SQL dialects have diverged in both directions, with each carrying features the other lacks.

For a new project the choice is genuinely open. For an existing MySQL deployment, migration is a project rather than a package swap, and worth testing properly.

For a new project where neither is a requirement, PostgreSQL is worth considering seriously, and our PostgreSQL guide covers getting it running, including the pg_hba.conf authentication model that confuses newcomers.

Upgrading

mariadb --version
sudo mariadb-upgrade

Major version upgrades want a tested backup and a read of the incompatibility notes first. Replication setups need the usual care about upgrade order, replicas before the primary.