2009 übernahm Oracle Sun Microsystems und damit MySQL. Monty Widenius, der ursprüngliche MySQL-Autor, traute Oracle die Open-Source-Pflege nicht zu und forkte den Code als MariaDB unter der MariaDB Foundation. Siebzehn Jahre später ist klar: beide Datenbanken haben sich auseinander entwickelt, der Drop-in-Replacement-Anspruch der frühen MariaDB-Jahre stimmt nur noch bedingt, und die Wahl zwischen ihnen ist 2026 eine echte technische Entscheidung.

Aktuelle LTS-Releases Mitte 2026

Aspekt	MySQL 8.4 LTS	MariaDB 11.4 LTS
Release-Datum	30. April 2024	16. Mai 2024
Support bis	April 2032 (8 Jahre)	Mai 2029 (5 Jahre)
Lizenz	GPLv2 + Commercial (Dual)	GPLv2 only
Default Storage Engine	InnoDB	InnoDB (Aria intern)
Default Charset	utf8mb4 / utf8mb4_0900_ai_ci	utf8mb4 / utf8mb4_uca1400_ai_ci
Min. RAM (sinnvoll)	~2 GB	~1 GB

MySQL 8.4 ist Oracles erstes 8.x-LTS-Release — vorher gab es nur Innovation-Releases mit kürzerem Support-Fenster. Acht Jahre Sicherheitsupdates sind in der Enterprise-Welt ein starkes Argument. MariaDB 11.4 LTS hat fünf Jahre Support, dafür einen klaren Community-Charakter ohne Oracle-Dual-Lizenz.

Architektur-Unterschiede

Replikation und Cluster

MySQL nutzt Group Replication als nativen Multi-Master-Modus mit zertifizierungs-basiertem Konsens (basierend auf einer Paxos-Variante). Maximal neun Nodes, synchrone Replikation, automatisches Member-Recovery. Für asynchrone Standard-Replikation hat MySQL 8.4 verbessertes Crash-Safe-Replication mit GTID-Default.

MariaDB hat sich für Galera Cluster als Multi-Master-Lösung entschieden — synchroner Replikator von Codership, der auch bei Percona XtraDB Cluster läuft. Galera ist seit Jahren produktions-erprobt, kostet aber Schreib-Performance bei großen Cluster-Größen (mehr als 5 Nodes wird wegen Round-Trip-Konsens unpraktisch).

In Benchmarks mit drei Nodes und Schreib-Last (sysbench OLTP write-only) liegen beide Lösungen ähnlich — MySQL Group Replication etwa 5-8 Prozent schneller bei niedriger Konkurrenz, Galera robuster bei Node-Ausfällen.

Storage Engines

MySQL 8.4 hat sich konsolidiert: InnoDB ist die einzige relevante Engine, MyISAM ist nur noch für Spezialfälle (Read-Only-Tabellen mit FULLTEXT) sinnvoll, NDB Cluster läuft separat.

MariaDB 11.4 unterstützt Aria (eine MyISAM-Weiterentwicklung mit Crash-Safety), MyRocks (RocksDB-basiert, gut für Write-heavy Workloads mit großen Datenmengen) und ColumnStore (analytische Workloads, Drop-in-Spaltenspeicher). Für ein Standard-OLTP-Workload bleibt InnoDB die Wahl, aber MyRocks kann bei einer 5 TB-Tabelle mit ständigem Insert-Stream signifikant Disk-IO sparen (etwa 50 Prozent kleinerer Footprint).

Document Store vs. JSON-Funktionen

MySQL liefert mit dem X-Protocol und MySQL Document Store ein NoSQL-Interface über die gleiche Engine — Collections als InnoDB-Tabellen mit JSON-Dokumenten. Sinnvoll, wenn ein Team beides parallel braucht (relational + document) ohne zweite Datenbank zu betreiben.

MariaDB verzichtet auf das X-Protocol, hat dafür eine vollständige JSON-Funktions-Suite (JSON_EXTRACT, JSON_VALUE, JSON_TABLE, JSON_OVERLAPS). Syntax ist nahe an MySQL, aber nicht identisch — JSON_VALUE hat in MariaDB seit 10.9 die SQL/JSON-Standard-Semantik, MySQL nähert sich erst in 8.4 an. Wer JSON-heavy Queries portiert, muss prüfen.

Performance-Benchmark

Methodisches Setup für realistische Vergleichbarkeit: sysbench 1.0.20, OLTP-Read-Write-Workload, 100 Tabellen je 1.000.000 Rows (~25 GB Daten), 64 Threads, identische Hardware (16 vCPU, 64 GB RAM, NVMe-Storage). Beide Datenbanken mit Standard-LTS-Defaults plus innodb_buffer_pool_size = 48G und innodb_log_file_size = 4G.

Workload	MySQL 8.4 (TPS)	MariaDB 11.4 (TPS)	Differenz
OLTP read-only	~24.500	~24.100	MySQL +1,6%
OLTP read-write	~9.800	~9.400	MySQL +4,3%
OLTP write-only	~7.200	~7.600	MariaDB +5,6%
Point Select	~78.000	~75.000	MySQL +4,0%
Update Index	~12.500	~13.100	MariaDB +4,8%

Die Größenordnung passt zu den unabhängigen Phoronix-Tests und Percona-Blog-Messungen aus 2025/2026: 5-15 Prozent Variabilität je nach Workload, kein klarer Sieger. MySQL profitiert auf Read-heavy Last vom InnoDB-Tuning-Vorsprung der Oracle-Entwickler, MariaDB liegt bei Write-Workloads vorne — vermutlich, weil MariaDB die InnoDB-Patches anders priorisiert (kleinere Lock-Contention bei Bulk-Inserts).

Faustregel: für ein typisches Web-Backend mit gemischter Last liegen beide innerhalb der Messungenauigkeit. Die Storage-Engine-Wahl (MyRocks für Write-extreme, ColumnStore für Analytics) verschiebt die Performance stärker als der Engine-Switch zwischen MySQL und MariaDB.

Speicher-Anforderungen

MySQL 8.4 ist deutlich speicher-hungriger im Idle-Zustand: leerer Server mit Default-Config belegt etwa 400-450 MB RAM, was für eine VPS-Instanz mit 1 GB RAM eng wird. Mit Buffer-Pool und Connection-Overhead sind 2 GB die untere praktische Grenze.

MariaDB 11.4 startet mit etwa 180-220 MB RAM Idle-Footprint. Eine 1-GB-VPS bekommt MariaDB problemlos als Backend für eine kleine WordPress-Installation gehostet. Für Shared-Hosting-Anbieter und kleine VPS-Setups ist das ein klares Argument.

Die Differenz erklärt sich durch optionale MySQL-Komponenten (Performance Schema mit größerem Standard-Footprint, MySQL Router-Bereitschaft, Group Replication aktivierbar), die MariaDB schlanker oder nicht ausliefert.

Lizenz-Unterschiede

MySQL läuft unter GPLv2 plus Oracle-Commercial-Lizenz. Wer MySQL in einem proprietären Produkt verbreiten will, kauft eine Oracle-Commercial-Lizenz und umgeht damit die GPL-Vererbung. Für SaaS-Anbieter ist das egal (kein Vertrieb), für On-Premise-Software-Hersteller wichtig.

MariaDB läuft rein unter GPLv2 (mit FOSS-Exception für Client-Libraries). Es gibt keine Commercial-Re-License-Option für den Server — wer MariaDB in einem proprietären Produkt nutzt, muss entweder die GPL-Verpflichtungen einhalten oder die Architektur so bauen, dass keine GPL-Vererbung auf den eigenen Code wirkt (Datenbank als externer Service, keine statische Linkung).

Für die meisten Web-Anwendungen ist die Lizenz-Frage praktisch irrelevant — beide laufen als externer Datenbank-Service ohne Lizenz-Verschmutzung des Anwendungs-Codes.

Migrations-Pfad MySQL zu MariaDB

In den meisten Fällen ist die Migration ein Drop-in-Replacement: MySQL stoppen, MariaDB installieren, datadir zeigen lassen, starten. MariaDB liest InnoDB-Tablespaces direkt.

Die Stolpersteine:

• JSON-Funktionen. JSON_EXTRACT ist kompatibel, aber Edge-Cases bei verschachtelten Pfaden weichen ab. JSON_TABLE ist seit MariaDB 10.6 und MySQL 8.0 verfügbar, aber die Signatur unterscheidet sich in COLUMN-Definitionen.
• Authentifizierung. MySQL 8 nutzt seit 8.0 caching_sha2_password als Default. MariaDB unterstützt das erst ab 10.4 vollständig. Bei Verbindungs-Problemen alte User auf mysql_native_password umstellen.
• Default-Charsets. MySQL 8.0+ verwendet utf8mb4_0900_ai_ci, MariaDB seit 10.10 utf8mb4_uca1400_ai_ci. Collation-Konversion in Tabellen explizit prüfen, sonst können Index-Lookups nach der Migration langsam werden.
• Window-Functions und CTE. Beide unterstützen es, aber MySQL hat performantere Implementierung in 8.4. Komplexe analytische Queries vor Cutover benchmarken.
• GIS-Funktionen. MySQL nutzt SRS-aware Geometry seit 8.0, MariaDB ist beim alten Verhalten geblieben. ST_-Funktionen mit explizitem SRID prüfen.

Migrations-Werkzeuge wie mariadb-upgrade (früher mysql_upgrade) führen den Schema-Konvertierungs-Pass nach dem Daten-Übernehmen aus.

Der umgekehrte Weg — MariaDB zu MySQL — ist deutlich schwieriger, weil MariaDB-spezifische Storage Engines (Aria, MyRocks) und Funktionen (REGEXP_REPLACE mit MariaDB-Semantik) auf MySQL nicht laufen. Plan: kein Drop-in, sondern Logical-Dump (mariadb-dump --compatible=mysql) und Re-Import.

Praktische Empfehlung 2026

• Open-Source-Projekt mit Community-Hosting. MariaDB 11.4 LTS. Kleinerer RAM-Footprint, klare GPL-Lizenz, gute Community-Verbreitung im Debian-/Ubuntu-Default. Synology, Red Hat und SUSE liefern MariaDB als Default.
• Enterprise mit Oracle-Support-Vertrag. MySQL 8.4 LTS. Längeres Support-Fenster (acht Jahre vs. fünf), kommerzielle Support-Optionen, Group Replication als ausgereifter Multi-Master.
• Heavy Write-Workload mit großen Datenmengen. MariaDB mit MyRocks-Engine — der Disk-Footprint-Vorteil rechtfertigt die Spezialisierung.
• Analytische Workloads (OLAP) parallel zu OLTP. MariaDB ColumnStore oder externe Lösung wie ClickHouse — beides nicht im MySQL-Default-Portfolio.
• WordPress-/Drupal-/Joomla-Hosting. Egal. Beide laufen, die Performance-Differenz ist unterhalb der Mess-Schwelle eines typischen CMS-Workloads.

Fazit

Die alte „MariaDB ist der bessere MySQL”-Erzählung stimmt 2026 nicht mehr und das Umgekehrte auch nicht. Es sind zwei produktreife Datenbanken mit klar unterscheidbarem Profil: MySQL liefert das längere Enterprise-Support-Fenster und die ausgereifteste Group-Replication, MariaDB den schlankeren Footprint, die freiere Lizenz und die breitere Storage-Engine-Auswahl. Wer 2026 neu anfängt, trifft die Wahl entlang dieser Profile — nicht entlang historischer Loyalität.