Oracle to MariaDB migration: MariaDB 13 helps, but target the LTS

Oracle licence costs are one of the most common reasons clients ask us about modernising a legacy system, and the hardest part of an Oracle to MariaDB migration is rarely the tables. It is the PL/SQL: packages, cursors and procedures that hold years of business logic. MariaDB Community Server 13.0, now generally available, closes two more of those gaps. It also comes with a catch that should shape your migration plan: 13.0 is a rolling release that will not receive bug-fix updates.

What MariaDB 13 adds for Oracle compatibility

According to MariaDB's GA announcement, 13.0 "deepens Oracle PL/SQL compatibility with REF CURSORs and RECORD types":

• REF CURSOR types. MariaDB now supports declaring TYPE ... IS REF CURSOR, both weak and strong, alongside the already supported SYS_REFCURSOR. Cursor variables declared this way can be opened, fetched from and closed like other cursors.
• RECORD in routine signatures. RECORD types can now be used as stored routine parameters and stored function return types, not only as local variables — the piece needed for routines that pass structured rows around, often alongside cursors.

There is a limit worth knowing before you plan around it. As InfoQ notes, REF CURSOR and RECORD are not yet supported as parameters or return types for non-package, global routines. In 13.0, REF CURSOR can be used inside packages and package bodies. Oracle code that passes cursors between standalone procedures will still need changes.

These build on MariaDB's long-standing SQL_MODE=ORACLE, which accepts a large subset of Oracle PL/SQL syntax, including packages.

Other changes in 13.0

• UPDATE ... RETURNING for single-table updates, with OLD_VALUE() to read both old and new values in one round trip.
• Optimizer hints that can target views, CTEs and derived tables without extra syntax.
• InnoDB log archiving, which keeps the write-ahead log as a sequential history for point-in-time recovery and incremental backups.
• Observability improvements, including new INFORMATION_SCHEMA columns and a visible init_rpl_role variable.

Should I use MariaDB 13 in production?

For an Oracle migration, probably not as your production target. MariaDB's own announcement is explicit: "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." It builds on MariaDB 12.3, the current long-term support release, and points towards the next LTS.

That distinction matters more for a migration than for a new application. A migrated enterprise system will run for years, and it needs a database version that will be patched for years. The sensible approach is:

• use 13.0 to test how much of your PL/SQL now runs with fewer changes;
• target production at an LTS release — the current one, or the next LTS if its timing fits your project and it carries the features you need;
• keep a list of code that depends on 13.0-era features, so you know exactly what the LTS must support before cutover.

Can MariaDB replace Oracle?

For many business applications, yes; for some, not economically. The migration is usually worth it when:

• licence and support costs are significant and rising;
• the PL/SQL is substantial but mostly standard — packages, procedures, cursors, exceptions;
• the application does not depend heavily on Oracle-only features such as advanced partitioning options, RAC-specific behaviour or proprietary extensions.

It is harder when business logic is spread across thousands of procedures with heavy use of features MariaDB does not support, or when third-party software certifies only on Oracle. PostgreSQL is the other common target and has its own mature Oracle-migration tooling; the right choice depends on your code, your team's skills and your hosting.

How to migrate Oracle PL/SQL to MariaDB

1. Inventory the code. Count packages, procedures, functions, triggers and types, and list the Oracle features they use. This is the estimate.
2. Pin down behaviour first. Before changing anything, capture what the current system does with tests at the database and application level. Our guide to characterization tests applies directly to stored procedures.
3. Run the code under SQL_MODE=ORACLE. Load schema and PL/SQL into a MariaDB test instance and record what fails. 13.0 is useful here, to see how much the new cursor and RECORD support removes.
4. Rewrite the remainder. Global routines passing cursors, unsupported types and Oracle-specific functions are the usual work.
5. Migrate data and compare. Run old and new side by side on real workloads and compare results, not just row counts.
6. Cut over on an LTS. Plan the production move on a supported long-term release.

How long does an Oracle to MariaDB migration take?

It is driven almost entirely by the volume and complexity of PL/SQL, and by test coverage. A schema with little procedural code can move quickly. A system with years of business logic in the database is a modernisation project, and should be run like one — incrementally, with the old system as the reference, as we set out in modernising legacy systems without breaking the business. Get the inventory before you get the estimate.

If Oracle licensing is a large line in your budget and you want to know what moving would really involve, our legacy application modernisation team can inventory your PL/SQL, test it against MariaDB and give you an estimate grounded in your code.