MariaDB 13.0 Preview Now Available

We are pleased to announce the availability of a preview of the MariaDB 13.0 series. MariaDB 13.0 is a preview rolling release, published on 23 March 2026, and it continues the work started in 12.3 while adding a solid set of entirely new features.

And this one is interesting.

This preview release brings a nice mix of new SQL capabilities, better optimizer insight, richer metadata, and practical engine improvements. Not every feature is flashy, but many of them are exactly the kind of changes that make daily work with MariaDB smoother, clearer, and just a bit more powerful.

We also would like to highlight that this new release includes a large number of Pull Requests from the Community, love it! Those community contributions are marked with .

What’s new in MariaDB 13.0 Preview

Compatibility and SQL language improvements

MariaDB 13.0 introduces several new SQL and procedural language capabilities, including:

  • support for TYPE .. IS REF CURSOR (MDEV-10152)
  • support for RECORD in routine parameters and function RETURN clauses (MDEV-38768)
  • a new optimizer hint: QB_NAME() (MDEV-38045)
  • support for reversed executable comments (MDEV-7381)

These are the kinds of additions that may look small in a feature list, but they matter. They improve expressiveness, broaden compatibility, and make procedural SQL work a little more smoothly and a little more powerfully.

Better observability and metadata

MariaDB 13.0 also improves the way the server exposes information about itself:

  • INFORMATION_SCHEMA.SYSTEM_VARIABLES now shows whether a variable is deprecated (MDEV-35369)
  • INFORMATION_SCHEMA.STATISTICS and INFORMATION_SCHEMA.COLUMNS now expose engine-specific create options (MDEV-36444)
  • Optimizer Trace now includes the optimizer statistics actually used (MDEV-36444)
  • The audit plugin log now supports a configurable timestamp format (MDEV-18386)

This is exactly the kind of work you appreciate when troubleshooting, tuning queries, or trying to understand why the optimizer made a particular choice. The more clearly the server explains itself, the better.

Engine, replication, and performance improvements

There is also a solid collection of practical lower-level changes in 13.0:

  • atomic CREATE OR REPLACE TABLE (MDEV-25292)
  • a new innodb_log_archive variable to preserve WAL instead of overwriting it in a ring buffer (MDEV-37949)
  • PERFORMANCE_SCHEMA now uses XXH3_128 for digests (MDEV-31669)
  • faster unique indexes on CHAR columns in MEMORY tables (MDEV-21543)
  • the default for binlog_row_event_max_size is now 64 KB (MDEV-37608)
  • default_master_connection can now be set globally (MDEV-9247)
  • CHANGE MASTER now resets Master_Server_Id in SHOW REPLICA STATUS (MDEV-15327)

Some of these are the kind of features that make you immediately say, “nice.” Others are the kind you only fully appreciate when you need them. Both kinds are, of course, welcome.

Why try the preview?

Preview releases are where you can see where MariaDB is headed next.

So if you’ve found new features applicable to your apps and use cases and want to get an early grip on them, test how they behave on real workloads, or simply get a feel for the next step in MariaDB’s rolling release line, this is a very good release to try. MariaDB’s public release policy also describes rolling releases as continuously updated releases announced quarterly.


Download MariaDB 13.0 preview.


A Feature in Focus

From now on, at each release, I will spotlight one feature. Let’s start with InnoDB Log Archive.

MariaDB 13.0 Preview introduced innodb_log_archive to preserve InnoDB WAL history, rather than letting old redo log entries disappear when the circular redo log wraps. This improves the backup story when the backup process takes too much time.

This global variable is dynamic, meaning you can change it at runtime:

MariaDB > set global innodb_log_archive=on;
Query OK, 0 rows affected (0.001 sec)

MariaDB > show global variables like 'innodb_log_archive';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_log_archive | ON    |
+--------------------+-------+
1 row in set (0.001 sec)

When enabled, we can see those archive log files appearing on the filesystem with the workload:

$ ls -lh ib*log
-r--r----- 1 fred fred 96M Mar 23 19:59 ib_0000000000003000.log
-rw-rw---- 1 fred fred 96M Mar 23 20:00 ib_0000000006000000.log

The size matches the size defined by innodb_log_file_size as the traditional circular redo log files:

MariaDB > select format_bytes(@@innodb_log_file_size);
+--------------------------------------+
| format_bytes(@@innodb_log_file_size) |
+--------------------------------------+
| 96.00 MiB                            |
+--------------------------------------+
1 row in set (0.000 sec)

The plan is to use those archived files to apply them during a backup restore. For example, you could take a full backup, note the last LSN, wait a day, copy the archived redo log to your backup system, and apply the new redo log from that LSN. This is the first step.

There is also an interesting variable, innodb_lsn_archived, that reports the earliest LSN for which recovery history is available:

MariaDB > show global status like 'innodb_lsn%';
+----------------------------+-----------+
| Variable_name              | Value     |
+----------------------------+-----------+
| Innodb_lsn_current         | 406265015 |
| Innodb_lsn_flushed         | 406265015 |
| Innodb_lsn_last_checkpoint | 402618295 |
| Innodb_lsn_archived        | 225587037 | <---
+----------------------------+-----------+
4 rows in set (0.001 sec)

We’re looking forward to hearing what you think. Your feedback is important to us during these previews. And of course, we want to thank all the developers who already contributed and encourage others to contribute to MariaDB.

Happy testing, enjoy MariaDB, and let us know about how you are using preview releases by answering our new poll.

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

One comment

  1. Hi, thank you for your work, I’ve been reading your blog and newsletter for a long time, and now that you’ve switched to MariaDB, I’d like to ask a few questions: 1. Is it possible to release a single stable and functional version? For example awaited 12.3 with really new feature for long time? 2. The installation documentation is installing rolling-release branches by default if no options selected, which aren’t particularly suitable for beginners. They end up installing a specific application on top of that, then turn to the vendor’s support and ask why it isn’t working. Are the LTS versions so bad that you don’t recommend them? Or are you just chasing new features for investors, and the more installations of the new versions, the better? 3. The MySQL documentation has always clearly explained what each option is and what a reasonable default limit should be. What will the situation be like in MariaDB? Right now, most of the documentation is either outdated or simply lists the options and their values without providing any useful information. 4. The official MariaDB Docker image or the version installed from packages complains when I try to use the client, saying I need to use the mariadb utility. But why do you still store all the paths in /etc/mysql and pretend to be MySQL, when you’re breaking compatibility with every release more and more? Why not just break it all at once and really screw things up? 5. It’s all very inconsistent—a little bit here, a little bit there, with lots of different versions. There’s 12.3.1, but it’s not stable; 13.0 has already been released, along with several LTS versions: 10.11, 11.4, and 11.8.

Leave a Reply

Your email address will not be published. Required fields are marked *