MySQL 8 vs. MariaDB: Unterschiede, die im Betrieb zaehlen

1. Die Fork-Geschichte: warum es MariaDB überhaupt gibt

MariaDB entstand 2009 als Fork von MySQL, initiiert von Michael Widenius, einem der ursprünglichen MySQL-Gründer, kurz nachdem Sun Microsystems MySQL AB übernommen hatte. Der Auslöser war die Sorge, dass ein grosser Konzernbesitzer, damals bereits absehbar Oracle, die offene Weiterentwicklung von MySQL einschränken könnte. MariaDB sollte als vollständig quelloffene, community-getriebene Alternative bestehen bleiben, unabhängig von einem einzelnen kommerziellen Eigentümer.

In den ersten Jahren war MariaDB praktisch ein Drop-in-Replacement für MySQL, mit identischem Datenformat und fast identischer SQL-Syntax. Diese enge Kopplung hat sich seither deutlich gelockert. Beide Projekte entwickeln inzwischen eigene Features mit eigener Roadmap, und die einst triviale Austauschbarkeit ist einer Situation gewichen, in der Migrationen in beide Richtungen sorgfältige Prüfung erfordern, statt ein reiner Binärtausch zu sein.

Für Betreiber bedeutet das: Die Entscheidung zwischen MySQL und MariaDB ist heute eine echte Architekturentscheidung mit langfristigen Konsequenzen, nicht mehr eine reine Lizenz- oder Distributionsfrage. Wer ein neues Projekt aufsetzt, sollte die tatsächlichen technischen Unterschiede kennen, statt sich auf die historische Kompatibilität aus den frühen Jahren zu verlassen.

2. Window Functions und Optimizer-Unterschiede

Window Functions wie ROW_NUMBER(), RANK() und LAG()/LEAD() wurden in MySQL mit Version 8.0 eingeführt, in MariaDB bereits mit Version 10.2, also früher. Syntaktisch sind beide Implementierungen heute weitgehend kompatibel zum SQL-Standard, sodass die meisten Window-Function-Abfragen unverändert auf beiden Systemen laufen. Unterschiede zeigen sich eher in Detailfällen und in der Optimizer-Behandlung komplexer Fensterfunktionen mit mehreren Partitionierungen.

Deutlicher divergieren die Optimizer selbst: MariaDB bringt mit dem Optimizer Trace und eigenen Histogramm-Implementierungen andere Heuristiken für Ausführungspläne mit als MySQL 8, dessen Cost-Based Optimizer seit Version 8.0 grundlegend überarbeitet wurde. In der Praxis heisst das, dass identischer SQL-Code auf beiden Systemen unterschiedliche Ausführungspläne und damit unterschiedliche Performance-Charakteristiken erzeugen kann, besonders bei komplexen JOINs mit mehreren Tabellen und Subqueries.

-- Window functions: syntax works on both MySQL 8 and MariaDB 10.2+
SELECT
  customer_id,
  order_date,
  total_amount,
  ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) AS rn,
  SUM(total_amount) OVER (PARTITION BY customer_id) AS customer_total
FROM orders;

-- Compare execution plans between engines with EXPLAIN
-- MySQL 8: cost-based optimizer with histogram statistics
EXPLAIN FORMAT=JSON
SELECT * FROM orders o JOIN customer c ON o.customer_id = c.id
WHERE c.region = 'DE';

-- MariaDB: optimizer trace for deeper plan analysis
SET optimizer_trace = 'enabled=on';
SELECT * FROM orders o JOIN customer c ON o.customer_id = c.id
WHERE c.region = 'DE';
SELECT * FROM information_schema.OPTIMIZER_TRACE;

3. JSON: nativer Typ vs. Alias-Lösung

Hier liegt einer der grössten praktischen Unterschiede zwischen den beiden Systemen. MySQL 8 hat einen echten, nativen JSON-Datentyp mit binärer Speicherung, Syntaxvalidierung beim Schreiben und dedizierten Funktionen wie JSON_TABLE. MariaDB hingegen implementiert JSON aus Lizenzgründen nur als Alias für LONGTEXT mit einer CHECK-Constraint, die die JSON-Syntax validiert, aber keine binäre Speicherung oder spezielle Indizierungsunterstützung bietet.

Das hat direkte Konsequenzen: Funktionen wie JSON_EXTRACT funktionieren in MariaDB zwar syntaktisch ähnlich, aber ohne die Performance-Vorteile des binären Formats aus MySQL. JSON_TABLE, ein zentrales Werkzeug für relationale Abfragen über JSON-Arrays, fehlt in MariaDB bis Version 10.6 komplett und wurde erst später mit eingeschränktem Funktionsumfang nachgerüstet. Wer eine Anwendung mit intensivem JSON-Einsatz plant, etwa für Produktattribute oder Event-Payloads, sollte diesen Unterschied unbedingt vor der Datenbankwahl berücksichtigen.

-- MySQL 8: native binary JSON type
CREATE TABLE product_attribute_mysql (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  attributes JSON NOT NULL,
  PRIMARY KEY (id)
) ENGINE=InnoDB;

-- MariaDB: JSON is a LONGTEXT alias with a validating CHECK constraint
CREATE TABLE product_attribute_mariadb (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  attributes LONGTEXT CHECK (JSON_VALID(attributes)),
  PRIMARY KEY (id)
) ENGINE=InnoDB;

-- JSON_EXTRACT works on both, but MariaDB re-parses text on every access
SELECT id, JSON_EXTRACT(attributes, '$.color') FROM product_attribute_mariadb;

4. Replikation: GTID, Parallelität und Failover

Beide Systeme unterstützen Global Transaction Identifiers für die Replikation, aber die Implementierungen sind untereinander inkompatibel. MySQL-GTIDs und MariaDB-GTIDs folgen unterschiedlichen internen Formaten, was bedeutet, dass ein direkter, gemischter Replikationsverbund zwischen einer MySQL- und einer MariaDB-Instanz nicht ohne Weiteres funktioniert. Für Migrationen zwischen den beiden Systemen ist deshalb meist ein logischer Export und Reimport statt einer nativen Replikationsverbindung nötig.

Bei paralleler Replikation, also der gleichzeitigen Anwendung mehrerer Transaktionen auf einem Replika-Server, verfolgen beide Projekte unterschiedliche Strategien. MariaDB bietet mit optimistischer paralleler Replikation seit Version 10.0 einen Mechanismus, der Transaktionen aggressiver parallelisiert und dabei Konflikte im Nachhinein erkennt, während MySQL 8 einen konservativeren, auf Write-Sets basierenden Ansatz nutzt. In der Praxis kann das bei sehr schreibintensiven Workloads zu spürbar unterschiedlichem Replikations-Lag führen, was bei der Kapazitätsplanung von Replika-Servern berücksichtigt werden sollte.

5. Storage Engines: InnoDB, Aria und die MariaDB-Extras

InnoDB ist in beiden Systemen die Standard-Engine, wird aber unabhängig weiterentwickelt, wobei MariaDB üblicherweise eine ältere InnoDB-Codebasis als Ausgangspunkt nutzt und eigene Patches einpflegt. MariaDB bringt zusätzlich eigene Storage Engines mit, die es in MySQL nicht gibt: Aria als transaktionssichere Alternative zu MyISAM für Systemtabellen, ColumnStore für analytische Workloads, und Anbindungen wie Spider für verteilte Tabellen über mehrere Server.

Diese zusätzlichen Engines sind ein echter Vorteil für spezialisierte Anwendungsfälle, spielen aber für den typischen Magento- oder Shop-Betrieb, der praktisch ausschliesslich auf InnoDB setzt, keine relevante Rolle. Wer nicht explizit einen Anwendungsfall für Aria, ColumnStore oder Spider hat, sollte diesen Unterschied nicht als Hauptkriterium für die Datenbankwahl werten, da er im Alltag kaum zum Tragen kommt.

6. SQL-Kompatibilitätsfallen im Alltag

Neben den grossen Architekturunterschieden gibt es eine Reihe kleinerer, aber tückischer SQL-Inkompatibilitäten. MySQL 8 hat mit utf8mb4_0900_ai_ci eine neue Standard-Collation eingeführt, die es in MariaDB nicht gibt, MariaDB bleibt bei utf8mb4_general_ci oder utf8mb4_unicode_ci als gängigen Defaults. Ein Dump aus MySQL 8 mit dieser Collation lässt sich nicht ohne Anpassung in MariaDB importieren, was bei Migrationen regelmässig zu Fehlern führt, wenn diese Details übersehen werden.

Auch bei CHECK-Constraints, Common Table Expressions und der Behandlung von INFORMATION_SCHEMA-Metadaten gibt es Detailunterschiede, die selten dokumentiert, aber in der Praxis relevant sind. Ein weiteres Beispiel: MySQL 8 hat Roles als eigenständiges Berechtigungskonzept eingeführt, MariaDB unterstützt Roles zwar auch, aber mit abweichender Syntax für Zuweisung und Vererbung. Wer Skripte oder Migrations-Tools für beide Systeme gleichzeitig pflegt, muss diese Details explizit testen, statt sich auf oberflächliche SQL-Kompatibilität zu verlassen.

-- MySQL 8 default collation, not available in MariaDB
CREATE DATABASE shop_mysql
  CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

-- MariaDB equivalent default
CREATE DATABASE shop_mariadb
  CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

-- Roles: similar concept, different syntax details
-- MySQL 8
CREATE ROLE app_readonly;
GRANT SELECT ON shop.* TO app_readonly;
GRANT app_readonly TO 'app_user'@'%';

-- MariaDB (syntax largely compatible, but privilege inheritance
-- and default role activation behave differently)
CREATE ROLE app_readonly;
GRANT SELECT ON shop.* TO app_readonly;
GRANT app_readonly TO app_user;
SET DEFAULT ROLE app_readonly FOR app_user;

7. Treiber, Tools und Ökosystem-Kompatibilität

Die meisten gängigen Datenbank-Treiber, darunter PDO_MySQL für PHP, funktionieren mit beiden Systemen weitgehend problemlos, weil sie auf dem gemeinsamen MySQL-Protokoll aufsetzen. Unterschiede zeigen sich eher bei administrativen Werkzeugen: Percona-Tools wie pt-online-schema-change unterstützen beide Systeme, aber mit teils unterschiedlichem Reifegrad, während MariaDB-eigene Tools wie mariabackup nicht für MySQL gedacht sind und Percona XtraBackup wiederum primär für MySQL optimiert ist, auch wenn es MariaDB grundsätzlich unterstützt.

Auch Managed-Database-Angebote grosser Cloud-Anbieter unterscheiden sich in ihrer Unterstützung: Manche bieten beide Systeme parallel an, andere nur eines davon, was die spätere Migration in eine Cloud-Umgebung beeinflussen kann. Vor einer langfristigen Entscheidung lohnt sich deshalb ein Blick auf die konkret geplante Hosting- und Backup-Infrastruktur, nicht nur auf die reine Datenbank-Engine.

8. Welche Datenbank für ein neues Magento-Projekt

Magento unterstützt offiziell sowohl MySQL 8 als auch bestimmte MariaDB-Versionen, was auf den ersten Blick nach freier Wahl aussieht. In der Praxis ist MySQL 8 für neue Magento-Projekte jedoch meist die risikoärmere Wahl, weil Magento selbst intensiv gegen MySQL getestet wird, die grosse Mehrheit der Produktionsinstallationen weltweit auf MySQL läuft und Support-Ressourcen aus der Community sich überwiegend auf MySQL-spezifische Probleme beziehen.

Ein weiterer praktischer Punkt: Magento nutzt an mehreren Stellen JSON-Spalten für Konfigurationsdaten und EAV-bezogene Strukturen. Die fehlende JSON_TABLE-Unterstützung und der Alias-Charakter von JSON in älteren MariaDB-Versionen können hier zu subtilen Performance-Unterschieden führen. Für bestehende Installationen, die bereits stabil auf MariaDB laufen, ist ein Wechsel nicht zwingend nötig, aber für ein komplett neues Projekt ohne bestehende MariaDB-Abhängigkeit ist MySQL 8 die pragmatischere Standardwahl.

9. MySQL 8 und MariaDB im direkten Vergleich

Die folgende Übersicht fasst die wichtigsten Unterschiede zusammen, die für die Betriebsentscheidung relevant sind.

Kein System ist in jeder Zeile klar überlegen, die Tabelle zeigt vor allem, dass die Wahl von den konkreten Prioritäten abhängt: JSON-intensive Anwendungen und maximale Magento-Kompatibilität sprechen für MySQL 8, spezialisierte Storage-Engine-Anforderungen und eine bevorzugt community-geführte Lizenzpolitik sprechen für MariaDB.

10. Zusammenfassung

MySQL und MariaDB begannen als nahezu identische Systeme, haben sich seither aber in mehreren technisch relevanten Punkten auseinanderentwickelt: dem JSON-Datentyp, der Optimizer-Architektur, dem Replikationsverhalten und einzelnen SQL-Details wie Collations und Rollen-Syntax. Die einst triviale Austauschbarkeit existiert heute nicht mehr, Migrationen zwischen beiden Systemen erfordern echte Prüfung statt eines reinen Binärtauschs.

Für ein neues Magento-Projekt ist MySQL 8 in aller Regel die risikoärmere Wahl, wegen der breiteren Testabdeckung, dem nativen JSON-Typ und der grösseren Verbreitung in Produktion. Bestehende, stabil laufende MariaDB-Installationen müssen deshalb nicht zwingend migriert werden, aber neue Projekte sollten die Entscheidung bewusst treffen, statt sie als reine Verfügbarkeitsfrage der Hosting-Umgebung zu behandeln.

11. FAQ: MySQL 8 vs. MariaDB