MariaDB Server is a community-developed, GPL-2.0 relational database server forked from MySQL by the original MySQL developers, aimed at teams that want MySQL compatibility with a sanely licensed, independently governed SQL server.

What it is

MariaDB Server is an open source relational database management system written in C++ and built by a global community of contributors together with the MariaDB Foundation and MariaDB plc. It began as a fork of MySQL led by the original MySQL developers and keeps a high degree of MySQL compatibility, so it remains a straightforward migration target for existing MySQL deployments. Over time it has grown capabilities of its own, including a native VECTOR data type, multiple pluggable storage engines, synchronous clustering, and analytical features. The MariaDB Foundation acts as custodian of the codebase, ensuring it stays open and that anyone can contribute.

The concrete problem it solves is licensing and governance of the database layer. It replaces MySQL Server for teams that want the same wire protocol and syntax without the licensing constraints attached to that product, and it adds features MySQL does not offer in the same form — most notably native vector search with approximate nearest-neighbour indexing, available since MariaDB 11.8 with no extension required. It lives in the relational database ecosystem, alongside the storage engines, replication topologies, and SQL tooling that surround any production RDBMS.

Key capabilities

• Native vector search: built-in VECTOR data type with approximate nearest-neighbour indexing (HNSW), no extension required, available since MariaDB 11.8.
• Pluggable storage engines: InnoDB for transactional workloads, Aria, MyRocks, ColumnStore for analytics, Spider for sharding, and S3 for archival, among others.
• Replication and clustering: asynchronous, semi-synchronous, and parallel replication with global transaction IDs, plus Galera synchronous multi-primary clustering.
• Advanced SQL: common table expressions including recursive CTEs, window functions, system-versioned (temporal) tables, sequences, and a broad set of JSON functions.
• MySQL and Oracle compatibility: wire-protocol and syntax compatibility with MySQL, plus an Oracle SQL mode supporting PL/SQL-style stored routines.
• Spatial and full-text search: GIS data types and functions, and built-in full-text indexing.
• Security: role-based access control, pluggable authentication including ed25519, PAM, and GSSAPI, data-at-rest encryption, and TLS for connections.

Who uses it and how

• Small applications through large-scale production systems run on the same server, so a deployment can start small and scale without changing the database.
• Teams migrating from MySQL use the wire-protocol and syntax compatibility to move existing workloads with minimal application change.
• Analytics workloads run on the ColumnStore engine, while sharded deployments use Spider and archival data can be pushed to the S3 engine.
• High-availability deployments use Galera synchronous multi-primary clustering, or asynchronous and semi-synchronous replication with global transaction IDs.
• Organisations with strict access requirements use role-based access control, pluggable authentication such as PAM or GSSAPI, data-at-rest encryption, and TLS for connections.

Getting started

Packages and installation instructions for all supported platforms are available at https://mariadb.org/download/. To build from source and run the test suite, follow the developer guide at https://mariadb.org/get-involved/getting-started-for-developers/get-code-build-test/.

How it compares

MariaDB Server is a fork of MySQL, so it sits beside that product as a compatible alternative rather than a different category of tool; the reference material explicitly documents MariaDB versus MySQL features and differences. The decisive contrast is licensing and governance: MariaDB Server is GPLv2 without the "any later version" clause inherited from MySQL, and the MariaDB Foundation is the custodian of the codebase, with releases on a yearly LTS model alongside quarterly rolling releases. LTS binaries are maintained for three years and recommended for production, while rolling releases deliver new features sooner with a shorter support window.

When to use it — and when not to

A self-hoster must operate the database itself — storage engines, replication or Galera clustering, TLS certificates, pluggable authentication, encryption keys, and backups — since the project ships no managed service. Teams that want a fully managed cloud database, or that need a non-relational data model, should look elsewhere. Two honest caveats: the GPLv2 licence is granted without the "any later version" clause, which some organisations treat as a constraint, and vector search only exists from MariaDB 11.8 onward, so older LTS deployments will not have it. The repository also carries a substantial open issue count, so users should expect an active but busy upstream.