MariaDB

What is MariaDB?

MariaDB is a fork of MySQL maintained by its original developers, and stays wire-compatible with it. Most applications written for MySQL work unchanged, which makes it the low-risk default when something asks for MySQL.

Best for

Apps that expect MySQL without the licensing questions

Why choose MariaDB

MariaDB exists because its maintainers wanted a MySQL that stayed open while remaining byte-compatible with everything already written for it. The practical consequence is that it is the low-risk answer whenever an application's documentation says MySQL: the drivers, the SQL dialect and most of the tooling work unchanged, and the migration is usually a connection string. It is also slightly ahead of MySQL on several engineering fronts, with better defaults for some storage engines and features like temporal tables that the community asked for. For a homelab or a small deployment, it means one well-understood relational database covering a large share of the applications you will install.

Replaces

• MySQL
• PostgreSQL
• Amazon Aurora

Key features

• MySQL wire compatibility
• Multiple storage engines including columnar options
• Galera clustering available
• Active community development

What to watch out for

Compatibility is high but not absolute. A few features diverge in behavior or exist in only one of the two, and applications that rely on MySQL-specific internals — particular JSON functions, specific replication commands — can fail in ways that are hard to diagnose. Third-party guides and Stack Overflow answers often assume MySQL, so advice can quietly be wrong for your engine. It also inherits the classic MySQL operational shape: replication is a separate system to run, and default character set and collation settings have historically caused subtle data problems if not set explicitly at creation time. Upgrades between major versions should be planned, not improvised.

How to deploy

• Docker with a persistent data volume
• Create a dedicated user per application
• Enable and test backups immediately

Getting started

Create the databases with an explicit character set and collation so you are not inheriting a default that will bite later. Give each application its own user with the minimum privileges it needs rather than one shared account. Set the memory parameters — buffer pool size in particular — based on the host instead of leaving defaults, and cap connections so one misbehaving app cannot exhaust the server. Include the data directory in a tested backup routine. If you are moving an existing MySQL install, do it as a dump and restore into a fresh instance rather than an in-place swap.

Typical setup

A single instance with an explicit character set and collation set at database creation rather than inherited, and a data directory on a volume that is backed up and test-restored. Buffer pool size and connection limits are tuned to the host, and each application connects with a dedicated least-privilege user. Where an existing MySQL install is being replaced, the migration is done as a dump and restore into a fresh instance. Where the data matters, replication is configured and a failover has been rehearsed rather than assumed.

Who should look elsewhere

Do not add MariaDB alongside a PostgreSQL you already run unless the application truly requires it, because two relational engines is two sets of backups, tuning and upgrade paths for no real gain. It is also the wrong choice for new projects that have no MySQL heritage — PostgreSQL is the better long-term default unless a specific dependency dictates otherwise. And if you need the commercial support contracts that only the vendor edition provides, the community fork is not that.

Project health

• GitHub stars: 8,308
• Last code push: 2026-10-02
• Open issues: 539
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.