MariaDB Community Server 13.0 GA deepens Oracle PL/SQL compatibility with REF CURSORs and RECORD types, gives developers UPDATE…RETURNING, expands manageability across INFORMATION_SCHEMA and SHOW VARIABLES, extends the new-style optimizer hint framework, and adds InnoDB log archiving for backup and point-in-time recovery.

Key takeaways

  • Richer Oracle PL/SQL Compatibility: Native support for REF CURSOR types and RECORD in routine parameters and function returns makes it easier to bring Oracle PL/SQL-based applications to MariaDB.
  • A Better Developer Experience: Single-table UPDATE ... RETURNING lets applications read back changed rows without a follow-up SELECT.
  • Sharper Observability & Manageability: New columns in INFORMATION_SCHEMA, a visible init_rpl_role variable, and deprecation flags for system variables make auditing and troubleshooting easier.
  • A Smarter Query Optimizer: The new-style optimizer hint framework now understands the structure of views, CTEs, and derived tables, so hints can reach deeper into a query without extra syntax.
  • Stronger Backup & Recovery: innodb_log_archive preserves InnoDB’s write-ahead log as a sequential history instead of a ring buffer, enabling point-in-time recovery and incremental backups.

We are excited to announce the General Availability of MariaDB Community Server 13.0. Building on the foundation laid by the MariaDB Community Server 12.3 LTS, this version pushes further into Oracle compatibility, gives developers a new way to retrieve data from UPDATE statements, and gives DBAs finer-grained tools for observability, query tuning, and backup and recovery.

As part of our quarterly rolling release cycle, MariaDB Community Server 13.0 GA is a rolling release and will not receive further bug-fix releases. We encourage everyone to explore these new capabilities as we continue toward the next Long-Term Support (LTS) release.

What’s New in MariaDB Community Server 13.0

Oracle PL/SQL Compatibility

Continuing its long-standing investment in Oracle PL/SQL compatibility, MariaDB 13.0 fills in gaps that make it easier to port stored routines and procedural logic from Oracle environments.

  • TYPE .. IS REF CURSOR: MariaDB now supports declaring REF CURSOR types, including both weak and strong typing, alongside the already-supported SYS_REFCURSOR. Cursor variables declared this way can be opened, fetched from, and closed like other cursors, bringing MariaDB’s cursor handling closer in line with Oracle’s PL/SQL. In 13.0, REF CURSOR can be declared inside package routines and in a PACKAGE BODY, and used as a local variable, package routine parameter, or package function RETURN type; it is not yet supported as a parameter or RETURN type for global (non-package) routines.
  • RECORD in Routine Parameters and Function RETURN: The RECORD type can now be used as the type of stored routine parameters and as the return type of stored functions, not just for local variables. This is also a foundational piece for making REF CURSOR support complete, since routines that return or accept cursors often need to pass structured row types along with them. As with REF CURSOR, this support in 13.0 is scoped to package routines and PACKAGE BODY; RECORD cannot yet be used as a parameter or RETURN type for global (non-package) routines.

Developer Experience

MariaDB 13.0 also gives application developers a more direct way to work with data changed by DML statements.

  • UPDATE … RETURNING: Single-table UPDATE statements can now include a RETURNING clause, returning a result set of the affected rows directly from the UPDATE itself. Combined with the OLD_VALUE() function, applications can retrieve both the pre- and post-update values of changed columns in one round trip, without issuing a separate SELECT. This joins the existing RETURNING support for INSERT and single-table DELETE, rounding out the set of DML statements that can hand back data to the client. Note that RETURNING is only supported for single-table updates; multi-table UPDATE does not support it yet.

Observability & Manageability

MariaDB 13.0 gives administrators clearer, more queryable insight into server configuration and schema metadata.

  • init_rpl_role in SHOW VARIABLES: The replication role set via the --init-rpl-role startup option is now exposed as a proper system variable, queryable with SHOW VARIABLES LIKE 'init_rpl_role' or SELECT @@init_rpl_role. Previously this setting could only be inspected by checking the server’s configuration file, making it harder to confirm a running server’s replication role at a glance.
  • CREATE_OPTIONS in I_S.STATISTICS and I_S.COLUMNS: Both tables now expose a CREATE_OPTIONS column, surfacing storage-engine-specific options for indexes and columns that were previously only visible via SHOW CREATE TABLE. This makes it much easier to inspect and audit engine-specific metadata programmatically.
  • Deprecation Status in I_S.SYSTEM_VARIABLES: This table now includes columns indicating whether a system variable is deprecated. DBAs and tooling can now query this information directly instead of relying on release notes or documentation to track which variables are on their way out.

Query Optimizer

The new-style optimizer hint framework, introduced in MariaDB 12.0 and 12.1, continues to mature.

  • Implicit Query Block Names: Every view, CTE, and derived table participating in a query now automatically receives an implicit query block name based on its own name/alias or position. This means hints can be applied to objects inside views, CTEs, and derived tables without first having to add an explicit QB_NAME() hint to them, making it substantially easier to tune complex, nested queries.
  • Locator QB_NAME hint: For cases where a query block sits inside a view or CTE and can’t be reached by its implicit or explicit name alone, a new locator form of the QB_NAME hint lets you specify a path to that query block, so hints can still be targeted precisely even in deeply nested query structures.

Backup & Recovery

  • innodb_log_archive: This new variable changes how InnoDB manages its write-ahead log. Instead of overwriting a fixed-size ring buffer (ib_logfile0), InnoDB writes a continuous, sequentially-named series of log files, retiring each one to read-only once a checkpoint completes in the next. This preserves a full history of the write-ahead log for as long as archiving is enabled, enabling point-in-time recovery to a specific Log Sequence Number (LSN) and supporting incremental backup strategies that were not previously possible with the ring-buffer model. This is particularly useful for InnoDB-only deployments or recovery scenarios where binary logs are not available or enabled. Note that as of this release, mariadb-backup does not yet support the innodb_log_archive=ON log format.

MariaDB Community Server 13.0 GA is now available as part of our rolling release cycle. This model ensures that new features and enhancements reach the community faster. As we continue these quarterly updates leading toward our next Long-Term Support (LTS) version (13.3), we invite you to test these latest capabilities in your environments.

Download MariaDB Community Server 13.0 GA here.