MariaDB may have started as a MySQL fork, following Oracle’s acquisition of MySQL, but with time it’s charted its own path. Over the last few major revisions, the open source RDBMS has added unique functions, greater compatibility with MySQL, and a suite of behaviors designed to make it a migration target for Oracle SQL users. Here’s a quick look at some of the best and most powerful new features in MariaDB.

Also see: 4 self-contained databases for your apps.

Opt-in Oracle compatibility

Ever since version 10.3, MariaDB has been steadily adding Oracle compatibility features, making it easier to port Oracle to MariaDB as-is.

Oracle compatibility is opt-in. All you need to do is issue the command SET SQL_MODE='ORACLE' to activate it for a given set of SQL statements. Existing MariaDB behaviors will also be preserved wherever possible.

Most Oracle compatibility features are geared to supporting Oracle SQL syntax, especially where it deviates from ANSI SQL or MariaDB. For instance, Oracle SQL allows you to call stored procedures using the name of the stored procedure rather than the CALL keyword.

But other recent changes to Oracle compatibility mode involve underlying behaviors, not just syntax. As of MariaDB 12.0, single triggers can execute on multiple INSERT/UPDATE/DELETE events, an Oracle SQL feature that’s difficult to replicate manually.

MariaDB (the company) also offers a migration tool that analyzes an Oracle SQL DDL export file (just the data definition, no actual data) and assesses how well it will run with MariaDB’s Oracle compatibility mode.

AI features: MCP servers and vector types

AI features are finding their way into (some might say infesting) most every data-centric software product. While MariaDB is no exception, its AI features look to be actual tools, not just marketing glaze.

MariaDB 11.8 added a native VECTOR data type, a way to embed information about text similarity in a database. This lets you use MariaDB as an engine for building things like natural-language queries, recommendation systems, RAG solutions, and general-purpose machine learning tasks. Much of the heavy lifting for such work can be done directly in the database, avoiding round trips to external applications.

Another recent AI addition makes MariaDB an extension of existing AI agents. The Model Context Protocol (MCP), provides a common way for LLMs to talk to external tooling—for instance, to search the web. MariaDB now offers its own MCP server components to make it easy for LLMs to query MariaDB instances. It’s also possible to use embeddings (via OpenAI, Gemini, or open Huggingface models) to perform semantic searches on documents stored in the database.

More JSON features

NoSQL databases gave developers the freedom to use open-ended schemas, defined as JSON documents, to store data. Conventional SQL databases have since added their own native JSON functionality, a useful way to get NoSQL’s flexibility without ditching conventional SQL’s formal schemas.

In MariaDB, there’s a JSON column type, which accepts text in JSON format and can be automatically validated with a JSON_VALID CHECK constraint. If you want your JSON data to follow strict data types, you can add constraints for specific keys (e.g., key year should always be a valid INTEGER).

SELECT queries can extract data from JSON columns by key:

SELECT id, name, JSON_QUERY(attr, '$.dates.release') AS release_year FROM movies

They can also filter by values:

SELECT id, name FROM movies WHERE JSON_VALUE(attr, '$.dates.release') = 1981

For more performant operations against JSON, you can create virtual columns that map to keys in the document, and also build indexes from those virtual columns:

ALTER TABLE movies ADD COLUMN
    release_year SMALLINT AS (JSON_VALUE(attr, '$.dates.release'));
CREATE INDEX releaseyears ON movies(release_year);

It’s also possible to modify the data without extracting the JSON and manipulating it. JSON_INSERT(), JSON_ARRAY_APPEND(), and JSON_REMOVE() all let you perform these kinds of in-place transformations faster and more reliably than trying to fiddle with the data manually outside of MariaDB.

Expanded optimizer hints

Experienced database developers appreciate having granular control over how queries execute. MariaDB has long had hints, or “modifiers,” for SELECT statements, such as HIGH_PRIORITY and FORCE INDEX.

With MariaDB 12.0 came so-called new-style optimizer hints, a way to apply hints to specific tables or indexes as well as globally. These hints are formatted as inline comments with /*+ and */ delimeters.

Expanded hints aren’t for everyday use. They force-enable (or disable) behaviors that typically work fine as-is, but in certain scenarios work better when explicitly controlled. For instance, an INDEX_MERGE hint tells the query optimizer which specific indexes to use—and no others—when performing index scans on multiple columns. This can speed up queries on a table with many indexes, or no composite index to cover a specific query. But don’t assume your ideas about how these optimizations work in theory will play out in practice. It’s always best to use an EXPLAIN statement along with a query optimization to find out if it does, in fact, speed things up.

Other new hints are useful for troubleshooting as well as performance. For instance, the MAX_EXECUTION_TIME() hint can abort a specific query after a certain number of milliseconds. This hint can be used to prevent “pathological” queries from tying up the system, but also as part of the process of debugging an existing query with a tendency to run wild.

A new XML type

Another forward-looking improvement, although it doesn’t actually do much yet, is a new XMLTYPE column type, introduced in MariaDB 12.3. Right now, all it does is accept a string of up to 4GB in size, and allow for selective replacement of XML with the UPDATEXML function. While there is no attempt to validate the XML or enforce a schema currently, those features are slated to land later, and to make XMLTYPE more functionally compatible with Oracle. It opens the path for future expansion.

Features still missing

As MariaDB has matured and started to take its own development path apart from MySQL, it’s introduced many features not found in MySQL, like dynamic or virtual columns. But the reverse also holds: Some MySQL features still aren’t present in MariaDB, at least not yet.

One major missing feature, MySQL resource groups, has been proposed but still needs work to be implemented. Other features will likely never be cross-compatible, like support for MySQL’s ‘packed’ (binary) storage format for JSON.

And, because MariaDB and MySQL have different and incompatible methods for global transaction IDs, you can use a MariaDB server as a replica for a MySQL server but not the other way around. On the upside, this means you can use replication as a migration strategy from MySQL to MariaDB. Just make sure you have compatible versions of both databases.