MariaDB 13.0 and 12.3 LTS on Layerbase

Short version: a MariaDB database on Layerbase Cloud can now be created on five lines, 10.11, 11.4, 11.8, 12.3 and 13.0. The default is still 11.8, and the build behind it is 11.8.9. The two new entries are 12.3.3 and 13.0.2, and the three existing lines were refreshed in the same pass to 10.11.19, 11.4.13 and 11.8.9. The same five lines are in the Layerbase CLI and the desktop app. 13.0 is the interesting release: UPDATE ... RETURNING, atomic CREATE OR REPLACE TABLE, InnoDB log archiving, and an optimizer trace that tells you which statistics it used. 12.3 is the line to pick if you would rather not think about your server again for a few years, because it is the LTS. Nothing changes about how you connect, and databases already on 11.8 stay on 11.8.

MariaDB shipped 13.0.2 as GA on September 15, 2026. We did not make it the default that week and are not going to. The version you create a database on is the version you keep, so a default has to be one we would be comfortable being stuck on, and 13.0 is explicitly not that kind of release. Offering it is a different question from defaulting to it, and both new lines are offered today.

Rolling and LTS are different products

Read this before the feature list, because it is what decides which line you pick.

13.0 is a rolling release: roughly a quarterly cadence, a short maintenance window, and no long-term support commitment, so a rolling line gets fixes for about as long as it takes the next one to arrive. MariaDB's own guidance is that LTS is for long-term maintenance and slower upgrade cycles, and rolling is for people who want the newest features and are prepared to keep moving.

12.3 is the LTS, with community support to June 12, 2029. From the 12.x series onward the scheme is predictable: every .3 release is the LTS for its major, and the rolling releases fill the gaps around it.

So the choice is not "newer versus older", it is how often you want to move. I am not going to put an end-of-life date on 13.0, because MariaDB has not published one.

What is actually in MariaDB 13.0

The official 13.0 changes page covers it in full. The items that change how you write or run things:

UPDATE ... RETURNING. Single-table updates can return the rows they touched, the way INSERT ... RETURNING and DELETE ... RETURNING already did. An update-then-select round trip collapses into one statement, and you stop needing a transaction just to read back what you wrote.

Atomic CREATE OR REPLACE TABLE. The statement existed; what is new is that a failure part way through no longer leaves the old table dropped and the new one not yet created. That is the difference between a migration that is safe to retry and one that is not.

QB_NAME() with implicit query-block naming. The optimizer hint names a query block so other hints can target it, and 13.0 names blocks implicitly inside views and CTEs. Hinting into a view used to be guesswork; now there is something to aim at.

Optimizer trace reports the statistics it used. A trace told you the plan it chose. It now tells you which statistics it chose it from, which is usually the actual question when a plan goes wrong on one server and not another.

Deprecation status in INFORMATION_SCHEMA.SYSTEM_VARIABLES. New columns mark which server variables are deprecated, so a pre-upgrade audit is a query instead of a diff against release notes.

InnoDB log archiving. innodb_log_archive keeps redo log segments rather than recycling them, the missing piece for point-in-time recovery built on the redo log instead of the binary log.

Smaller items. PERFORMANCE_SCHEMA hashing moved to XXH3_128, the audit log timestamp format is configurable, and the binlog_row_event_max_size default rose to 64k. 13.0 also introduces the DuckDB storage engine at gamma maturity, which is not something you get here yet.

What a managed MariaDB on Layerbase gets from that

Honesty section. Everything above is server-side behavior, so it applies to a managed database here as-is: UPDATE ... RETURNING, the atomic CREATE OR REPLACE TABLE, the hint and trace work, the INFORMATION_SCHEMA columns and innodb_log_archive all come with the build.

What you do not get:

The DuckDB storage engine is not available on our MariaDB builds. It is gamma upstream, and more to the point we have not validated backup and restore of DuckDB-backed tables. A table you can create and cannot prove you can restore is worse than a table you cannot create, so it is left out until that leg is done. The VIDEX engine is not in our builds either. For columnar work today, ClickHouse and DuckDB are their own engines here, with their own validated backup and restore paths.

13.1 is not offered. It is at release candidate as I write this, and it carries two changes that need their own validation first: the default character set moves from utf8 to utf8mb4, and mariadb-dump changes behavior. Both are fine on a fresh database and interesting on an existing one. It will show up when it clears the gate, and I would rather say "not yet" than put a date on it and miss.

What 12.3 changed

If you are coming from 11.8, 12.3 is a smaller step than the version number suggests, but four items are worth knowing:

CONVERSION and TO_DATE became reserved words. If either is an unquoted identifier anywhere in your schema or queries, quote it with backticks before you move.
The caching_sha2_password plugin was added for MySQL compatibility. That is what a default MySQL 8 server authenticates with, so it closes a long-standing gap when you replay credentials or point MySQL-shaped tooling at MariaDB.
Foreign key names only need to be unique per table, not per schema, so generated migration names collide far less often.
Galera moved out of the standard server packages. No effect on a managed single instance here, but it will surprise anyone rebuilding a cluster locally from distribution packages.

Nothing changes when you connect

The defaults are identical on 11.8.9, 12.3.3 and 13.0.2: the same server character set and collation (utf8mb4 and utf8mb4_uca1400_ai_ci), the same default authentication plugin (mysql_native_password), innodb_snapshot_isolation on, the same sql_mode. We checked rather than assumed, and it is why this post is short on migration advice. An application that works against 11.8 needs no connection change and no character set change on 12.3 or 13.0.

mysql2, Prisma, Drizzle, PDO, and the mysql and mariadb command line clients all connect the way they did. MariaDB on Layerbase takes a dedicated port with native TLS, and every Layerbase surface comes along on all five lines: the pooled endpoint, the PlanetScale-compatible HTTP endpoint for runtimes that cannot hold a TCP socket, hibernate and wake, backups, and restores. Nothing in that list is version-gated.

Already on 11.8? Nothing moves underneath you

Databases created on 11.8 stay on 11.8, and the same goes for 10.11 and 11.4. Start, stop, backup, restore, branching and creating a new database on an older line all still work. The patch refresh changes what a new database on those lines boots with, not what an existing one runs. That is policy, not accident: a major version bump you did not schedule is an incident, not an upgrade.

It is also a one-way door. MariaDB does not support downgrading between majors, so once a data directory has been opened by a newer server the older server will not take it back. Moving an existing database between lines is therefore a dump and restore into a new database, not a switch you flip. Moving a MySQL dump into hosted MariaDB has the flags and the restore errors, and they are the same commands for a MariaDB source.

On the free tier

MariaDB is on the Free plan: two databases, 5 GB, up to 20 concurrent connections, one instant branch per database, one manual backup slot, and no credit card. All five lines are available there, so 13.0 can meet your test suite before it costs anything.

The part worth planning around is sleep. A free MariaDB hibernates after 30 minutes with no connections and wakes on connect, with the first connection held open while the engine starts. The cold start runs about 20 seconds, longer than some client connect timeouts (mysql2 gives up after 10 by default), so allow a 30 second connect timeout or start the database from its page first.

Verified, not assumed

Every version we offer, a new major or a patch refresh, clears the same gate before it reaches the version picker: the binary boots and serves on every platform we build for, backup and restore round-trip, the pooled and HTTP endpoints answer, and a live database reports what it should. Both new lines cleared that gate on staging and then again on production: a real 13.0 and a real 12.3 database were created on the production fleet on September 18, 2026 and answered on all three paths, the direct port, the pooled endpoint and the public hostname. Against a freshly created 13.0 database:

bash

mysql -h <host> -P <port> -u <user> -p<password> \
  -e "SELECT VERSION(), @@character_set_server, @@collation_server, @@innodb_snapshot_isolation"

text

VERSION()                   13.0.2-MariaDB
@@character_set_server      utf8mb4
@@collation_server          utf8mb4_uca1400_ai_ci
@@innodb_snapshot_isolation 1

Run it on an 11.8.9 and a 12.3.3 database and only the first row differs. That is the whole compatibility story.

FAQ

Which MariaDB versions does Layerbase offer?

10.11, 11.4, 11.8, 12.3 and 13.0. The default for a new database is 11.8, currently 11.8.9; the other builds are 10.11.19, 11.4.13, 12.3.3 and 13.0.2. The same set is in the Layerbase CLI and the desktop app.

Should I pick 12.3 or 13.0?

12.3 if the database should keep working without attention: it is the LTS, with community support to June 12, 2029. 13.0 if you want the new features now and are prepared to move again, because it is a rolling release with a short maintenance window and no long-term support commitment. From 12.x onward, every .3 is the LTS for its major.

Will my existing MariaDB database be upgraded to 13.0?

No. The version you created on is the version you keep, and 10.11, 11.4 and 11.8 stay fully supported for start, stop, backup, restore, branching and new databases. MariaDB does not support downgrading between majors, so moving an existing workload to a newer line means creating a database there and restoring a dump into it.

Do I need to change my client or connection string for 12.3 or 13.0?

No. Character set and collation, the default authentication plugin, innodb_snapshot_isolation and sql_mode are identical on 11.8.9, 12.3.3 and 13.0.2, and the pooled endpoint, the PlanetScale-compatible HTTP endpoint, hibernate and wake, backups and restores work the same on every line.

Can I use the DuckDB storage engine in MariaDB 13.0 here?

No. It is gamma maturity upstream and we have not validated backup and restore of DuckDB-backed tables, so it is left out of our builds until that is proven, and VIDEX is not included either. For columnar work, ClickHouse and DuckDB are separate engines on Layerbase with their own validated backup and restore.

Is MariaDB 13.1 available?

Not yet. It is at release candidate, and it changes the default character set from utf8 to utf8mb4 and alters mariadb-dump behavior. Both get their own validation before 13.1 is offered.

Is MariaDB on the free tier?

Yes, on every line. Two databases, 5 GB, up to 20 concurrent connections, one instant branch per database, one manual backup slot, and no card. A free MariaDB sleeps after 30 minutes idle and wakes on connect, with a cold start of about 20 seconds.

Create a MariaDB database and pick your line at create time. If you have been waiting to read back an update without a second query, 13.0 is the one.