--- title: "Announcing MariaDB Community Server 13.0 GA" publish_date: 2026-09-15 author: "Ralf Gebhardt" tags: - name: "backup" url: "/resources/blog/tag/backup.md" - name: "Community Server" url: "/resources/blog/tag/community-server.md" - name: "InnoDB" url: "/resources/blog/tag/innodb.md" - name: "Optimizer" url: "/resources/blog/tag/optimizer.md" - name: "PL/SQL" url: "/resources/blog/tag/pl-sql.md" --- # Announcing MariaDB Community Server 13.0 GA 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](https://mariadb.com/resources/blog/mariadb-community-server-12-3-lts-how-it-scales-ai-workloads-and-delivers-4x-write-performance/), 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](https://mariadb.com/resources/blog/announcing-yearly-lts-releases-for-mariadb-community-server/), 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**](https://mariadb.com/docs/server/reference/sql-statements/programmatic-compound-statements/declare-type#ref-cursor-types)**:** 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**](https://mariadb.com/docs/server/reference/sql-statements/programmatic-compound-statements/declare-type#record-types) **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**](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/changing-deleting-data/update)**:** 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](https://mariadb.com/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables#init_rpl_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**](https://mariadb.com/docs/server/reference/system-tables/information-schema/information-schema-tables/information-schema-statistics-table) **and** [**I\_S.COLUMNS**](https://mariadb.com/docs/server/reference/system-tables/information-schema/information-schema-tables/information-schema-columns-table)**:** 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**](https://mariadb.com/docs/server/reference/system-tables/information-schema/information-schema-tables/information-schema-system_variables-table)**:** 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](https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/optimizer-hints/query-block-naming#implicit-names-based-on-aliases) or [position](https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/optimizer-hints/query-block-naming#implicit-names-based-on-aliases). This means hints can be applied to objects inside views, CTEs, and derived tables without first having to add an explicit [QB\_NAME()](https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/optimizer-hints/query-block-naming) hint to them, making it substantially easier to tune complex, nested queries. - [**Locator QB\_NAME hint**](https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/optimizer-hints/query-block-naming#explicit-query-block-names-with-path)**:** 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**](https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-system-variables#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](https://mariadb.com/docs/server/server-usage/backup-and-restore/innodb-log-archive-pitr) 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](https://mariadb.com/downloads/community/community-server/).