MariaDB Server: a GPLv2 MySQL fork with native vector search and Galera clustering

What MariaDB Server solves, and for whom

The repository starts from a specific position: MariaDB began as a fork of MySQL, led by the original MySQL developers, and the README states it maintains a high degree of MySQL compatibility. That sentence is the product. If you have an existing MySQL deployment, the migration target is the same wire protocol and much of the same syntax, so the cost of moving is mostly operational rather than a rewrite.

The audience is therefore narrower than "anyone who needs a database". It is teams that want an open SQL server under a licence they can read, and that want capabilities the fork has added on its own: a built-in VECTOR data type with approximate nearest-neighbour indexing using HNSW, available since MariaDB 11.8 with no extension required; pluggable storage engines including InnoDB as the default for transactional workloads, Aria, MyRocks, ColumnStore for analytics, Spider for sharding and S3 for archival; and Galera synchronous multi-primary clustering. The topics list on the repository mirrors this: galera, innodb, vector-database, nearest-neighbor-search, fulltext-search, geographical-information-system.

It is not aimed at someone who wants a managed service with a support contract attached. The README points to the MariaDB Foundation and MariaDB plc as the organisations behind it, and to Zulip, a mailing list and Jira for help. That is a community support model, and the documentation is explicit about it.

How the server is put together: storage engines, replication and the VECTOR type

The architecture visible in the repository is the classic MySQL lineage: a server layer (sql/, sql-common/, include/) sitting on top of a storage engine layer (storage/), with client libraries in client/ and libmariadb, and the test framework in mysql-test/. The top-level entries also include wsrep-lib, the library behind Galera replication, and plugin/ for loadable components.

The practical consequence of that split is that the storage engine is a choice, not a given. InnoDB is the default for transactional workloads. Aria, MyRocks, ColumnStore, Spider and S3 appear as alternatives with different trade-offs, and the repository layout reflects that they live side by side under storage/. If you have used MySQL, the mental model transfers directly; if you have not, the important thing to internalise is that DDL and durability characteristics can change with the engine.

Replication is documented as asynchronous, semi-synchronous and parallel, with global transaction IDs, plus Galera for synchronous multi-primary clustering. Global transaction IDs are what make failover and topology changes tractable, because a replica can be pointed at a different primary without recomputing binlog positions by hand.

The newer piece is vector search. The README describes a native VECTOR data type with approximate nearest-neighbour indexing (HNSW), since 11.8, with no extension required. That last clause is the design claim: the index lives in the server rather than in a separate service, so a query can combine a vector distance condition with ordinary relational predicates in one statement. The README does not document the recall or latency characteristics of the HNSW index, and those are the numbers you would need to measure yourself before putting it in a production path.

Getting MariaDB Server and running a first query

The README does not embed install commands. It says packages and installation instructions for all supported platforms are available at the download page, and that building from source and running the test suite is covered by the developer guide. So the honest first step is to fetch the package for your platform from that page rather than copy a command from here.

What the README does give is the shape of the project once it is running. The server layer and the storage engine layer are separate directories in the tree, and the tools you interact with live under client/. The reference manual, linked from the README, is where the SQL surface is documented: common table expressions and recursive CTEs, window functions, system-versioned tables, sequences, and JSON functions.

For a first real use, the README points at the developer guide for building the code correctly, running the MariaDB testing framework, and choosing the right branch to target for contributions. That guide is also the reference for the build system driven by CMakeLists.txt and BUILD-CMAKE, and for the test framework in mysql-test/.

If you are coming from MySQL, the README notes wire-protocol and syntax compatibility, so existing client tooling should connect. What differs is what you can do next: system-versioned tables, sequences, recursive CTEs, and the VECTOR type. The README does not give a worked example of creating a VECTOR column or building the HNSW index, so treat that as something to read up on in the reference manual before designing a schema around it.

Where MariaDB Server is the wrong choice

The licence is the first boundary. MariaDB Server is GPLv2 without the "any later version" clause, inherited from MySQL, with third-party terms in the THIRDPARTY file. If you embed the server in a product you distribute, GPLv2 obligations apply to that distribution, and the repository does not offer an alternative licence. That is a structural constraint, not a bug, and it is the reason some commercial products pick a permissively licensed engine instead.

Compatibility is the second boundary, and it cuts both ways. The README claims a high degree of MySQL compatibility and links to a MariaDB-vs-MySQL page, which is an admission that the two are not identical. Anything relying on MySQL-specific internals, or on features that only exist upstream, needs checking against that page rather than assumed.

The third boundary is operational. Galera gives synchronous multi-primary clustering, but synchronous replication means write latency is bounded by the slowest node in the cluster, and a partitioned node cannot commit. If your workload tolerates asynchronous replication and you want the simplest possible topology, Galera is extra machinery. The repository also ships a large test framework in mysql-test/ and a build system driven by CMakeLists.txt and BUILD-CMAKE; contributing changes means learning that toolchain.

Finally, there is support. Help is via Zulip, the Maria Discuss mailing list and Jira. There is no documented SLA in the README. Teams that need a contractual escalation path should treat that as a gap to resolve before adoption, not after.

MariaDB Server compared with PostgreSQL

The obvious alternative for a team starting fresh is PostgreSQL, and the difference in approach is not cosmetic. MariaDB's pitch is continuity with MySQL: the same wire protocol, the same client tooling, and a migration path for existing deployments. PostgreSQL asks you to accept a different protocol, a different set of extensions and a different operational vocabulary, in exchange for a feature set that has evolved independently.

On vector search specifically, both projects now offer native types and approximate indexes, but they arrived by different routes and the index parameters are not interchangeable. If vector search is the deciding factor, the useful comparison is not the feature list but the query planner behaviour on your data, which neither README will tell you.

On clustering, MariaDB's Galera is synchronous multi-primary and ships inside the server tree (wsrep-lib is a top-level entry). PostgreSQL's equivalent is an external ecosystem rather than a single documented mode. On storage engines, MariaDB exposes a pluggable layer with InnoDB, Aria, MyRocks, ColumnStore, Spider and S3 as options; PostgreSQL's storage layer is not pluggable in the same way. If you want to swap engines per table, that is a genuine MariaDB advantage. If you want one well-tuned engine and no choices, it is a distraction.

The deciding question is usually existing investment. A shop with MySQL schemas, MySQL drivers and MySQL operational runbooks gets more from MariaDB than from PostgreSQL, because the migration is incremental. A greenfield project with no MySQL history has no such gravity, and should compare the two on the features it actually needs.

Release cadence, upgrade cost and licence implications

The README describes a yearly long-term support model alongside quarterly rolling releases. Binary LTS releases are maintained for three years and are recommended for production; rolling releases deliver new features sooner with a shorter support window. That is the upgrade calculus in one sentence: pick an LTS branch for production, and accept that new features arrive on a slower schedule.

The recent releases illustrate the parallel tracks. On 2026-08-24 the project published 12.3.3, 11.8.9 and 11.4.13 within minutes of each other, which is consistent with maintaining several branches at once. If you run 11.4, you are on a different line from someone running 12.3, and the features available to you differ. The last push to the repository was on 2026-09-15.

Upgrade cost is dominated by two things. First, storage engine changes: switching from InnoDB to MyRocks or ColumnStore is not a version bump, it is a migration with its own validation. Second, replication topology: if you use Galera, a rolling upgrade has to respect quorum, and the README does not document a rollback procedure for a failed cluster upgrade. That silence is worth noting; you should establish your own rollback path before touching a production cluster.

On licensing, GPLv2 without the "any later version" clause means you cannot unilaterally relicense the code under GPLv3. The COPYING file holds the licence text and THIRDPARTY holds third-party terms. Whether your distribution model is compatible with GPLv2 is a question for your own counsel; the repository only states the terms, it does not interpret them for you.

Editorial conclusion

Adopt MariaDB Server if you already run MySQL, need wire-protocol compatibility, and want native vector search (VECTOR plus HNSW, since 11.8) or synchronous multi-primary clustering through Galera without adding an extension. Do not adopt it if you need a commercial support contract from Oracle, or if your application depends on MySQL-only internals that the compatibility page does not cover. Before committing, verify three things against your own workload: the exact LTS branch you will run (11.4, 11.8 or 12.3, each with its own support window), whether your storage engine of choice is InnoDB or something like MyRocks or ColumnStore, and whether GPLv2 without the "any later version" clause fits how you distribute your product.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. MariaDB/server on GitHub
3. Project website
4. README
5. Releases