MariaDB vs. MySQL 2026: Technische Unterschiede die wirklich zählen

1. Warum MariaDB vs. MySQL 2026 noch immer relevant ist

MariaDB und MySQL teilen einen gemeinsamen Ursprung, haben sich aber seit dem Oracle-Kauf von Sun Microsystems 2010 erheblich auseinanderentwickelt. Wer heute eine neue Infrastruktur plant, muss zwischen beiden wählen — und wer eine bestehende betreibt, stößt früher oder später auf subtile Unterschiede, die in der Produktionspraxis teuer werden können. Die Systeme klingen gleich, verhalten sich aber in mehreren zentralen Bereichen grundlegend anders.

MariaDB vs. MySQL ist dabei kein akademisches Thema. Es trifft konkret: Replikationssetups mit GTID, Anwendungen die JSON-Spalten nutzen, Hochverfügbarkeitsarchitekturen und Magento-Shops, die offiziell MySQL voraussetzen, aber häufig auf MariaDB laufen. Dieser Artikel zeigt die Unterschiede dort, wo sie wirklich zählen.

2. JSON-Datentyp: Binary vs. LONGTEXT

Einer der markantesten Unterschiede zwischen MySQL 8 und MariaDB liegt beim JSON-Datentyp. In MySQL 8 ist JSON ein echter nativer Binärtyp. Das Dokument wird beim Speichern in ein kompaktes binäres Format konvertiert, das direkten Zugriff auf Teilpfade erlaubt, ohne das gesamte Dokument zu parsen. Das ist ein erheblicher Performance-Vorteil bei großen JSON-Dokumenten und häufigen Zugriffen auf einzelne Felder.

MariaDB geht einen anderen Weg: JSON ist dort ein Alias für LONGTEXT mit einer CHECK-Constraint, die sicherstellt, dass der gespeicherte Wert valides JSON ist. Es gibt keine Binäroptimierung. Jeder Zugriff auf ein JSON-Feld bedeutet in MariaDB vollständiges Parsen des gespeicherten Strings.

-- MySQL 8: nativer Binärtyp mit effizientem Pfad-Zugriff
CREATE TABLE product_meta (
    id INT PRIMARY KEY AUTO_INCREMENT,
    attributes JSON NOT NULL
);

-- Partieller Zugriff ohne volles Parsen (MySQL 8 intern)
SELECT JSON_EXTRACT(attributes, '$.color') AS color
FROM product_meta
WHERE JSON_EXTRACT(attributes, '$.in_stock') = true;

-- MariaDB: JSON ist LONGTEXT mit CHECK
-- Intern identisch mit:
CREATE TABLE product_meta (
    id INT PRIMARY KEY AUTO_INCREMENT,
    attributes LONGTEXT NOT NULL CHECK (JSON_VALID(attributes))
);

Die Konsequenz ist praktisch: Anwendungen, die viele JSON-Spalten und häufige JSON-Path-Abfragen nutzen, profitieren in MySQL 8 von signifikant besserem Performance-Verhalten. In MariaDB sollte man JSON-Zugriffe gezielt minimieren oder häufig abgefragte Werte in eigene Spalten auslagern.

3. SEQUENCE Engine in MariaDB

MariaDB bietet eine SEQUENCE Engine, die sequenzielle Zahlengeneratoren als eigenständige Datenbankobjekte ermöglicht — vergleichbar mit Oracle SEQUENCE oder PostgreSQL SEQUENCE. MySQL kennt dieses Konzept nicht. Dort muss man AUTO_INCREMENT-Spalten, separate Counter-Tabellen oder Anwendungslogik für sequenzielle Werte verwenden.

-- MariaDB: SEQUENCE direkt erstellen
CREATE SEQUENCE order_seq
    START WITH 1000
    INCREMENT BY 1
    MINVALUE 1000
    MAXVALUE 9999999
    NOCYCLE;

-- Nächsten Wert abrufen
SELECT NEXTVAL(order_seq);

-- Aktuellen Wert lesen (ohne Erhöhung)
SELECT LASTVAL(order_seq);

-- Wert setzen
SELECT SETVAL(order_seq, 5000);

-- In einer INSERT-Abfrage verwenden
INSERT INTO sales_order (increment_id, customer_id)
VALUES (LPAD(NEXTVAL(order_seq), 9, '0'), 42);

Das SEQUENCE-Objekt in MariaDB ist transaktionssicher, kann über Replikation propagiert werden und erlaubt exakte Kontrolle über Bereich, Schrittweite und Wrap-Around-Verhalten. Für Anwendungen, die auf portablen Code zwischen verschiedenen DBMS angewiesen sind, ist das ein echter Vorteil.

4. System-versioned Tables (Temporal Tables)

MariaDB unterstützt system-versioned Tables seit Version 10.3. Damit lässt sich die vollständige Änderungshistorie einer Tabelle automatisch durch die Datenbank erfassen, ohne Trigger oder Audit-Tabellen manuell pflegen zu müssen. MySQL bietet dieses Feature nicht nativ an.

-- MariaDB: system-versioned Table erstellen
CREATE TABLE product_price (
    id INT PRIMARY KEY,
    sku VARCHAR(64) NOT NULL,
    price DECIMAL(12,4) NOT NULL
) WITH SYSTEM VERSIONING;

-- Preis ändern
UPDATE product_price SET price = 19.99 WHERE id = 1;
UPDATE product_price SET price = 24.99 WHERE id = 1;

-- Aktuellen Stand abrufen
SELECT * FROM product_price WHERE id = 1;

-- Historischen Stand zu einem bestimmten Zeitpunkt abfragen
SELECT * FROM product_price
FOR SYSTEM_TIME AS OF '2025-01-01 12:00:00'
WHERE id = 1;

-- Gesamte History eines Datensatzes ansehen
SELECT *, ROW_START, ROW_END
FROM product_price
FOR SYSTEM_TIME ALL
WHERE id = 1
ORDER BY ROW_START;

-- Alle Änderungen in einem Zeitraum
SELECT * FROM product_price
FOR SYSTEM_TIME BETWEEN '2025-01-01' AND '2025-02-01'
WHERE id = 1;

Temporal Tables sind besonders nützlich für Compliance-Anforderungen, Preishistorien in Shops oder Audit-Logs ohne zusätzlichen Applikationscode. Der Overhead ist gering, da MariaDB die Historisierung intern über spezielle Systemspalten (ROW_START, ROW_END) mit Zeitstempeln verwaltet.

5. Window Functions: Gleichstand auf unterschiedlichen Wegen

Bei Window Functions sind beide Systeme funktional gleichwertig: MySQL unterstützt sie seit Version 8.0, MariaDB seit Version 10.2. Die Syntax ist weitgehend kompatibel. Dennoch gibt es Unterschiede im Optimizer-Verhalten und in einzelnen Randfällen.

-- Umsatz-Ranking pro Kategorie (funktioniert in MySQL 8 und MariaDB 10.2+)
SELECT
    category_id,
    sku,
    revenue,
    RANK() OVER (PARTITION BY category_id ORDER BY revenue DESC) AS revenue_rank,
    LAG(revenue, 1) OVER (PARTITION BY category_id ORDER BY created_at) AS prev_revenue,
    SUM(revenue) OVER (PARTITION BY category_id) AS category_total
FROM product_sales
ORDER BY category_id, revenue_rank;

-- Laufende Summe über Zeit
SELECT
    DATE(created_at) AS sale_date,
    SUM(grand_total) AS daily_revenue,
    SUM(SUM(grand_total)) OVER (ORDER BY DATE(created_at)) AS cumulative_revenue
FROM sales_order
WHERE status = 'complete'
GROUP BY DATE(created_at)
ORDER BY sale_date;

MariaDB hat in einigen Versionen Probleme mit der Materialisierung von Window-Function-Ergebnissen in CTEs gezeigt. MySQL 8 ist hier in aktuellen Versionen etwas konsistenter. Bei komplexen analytischen Queries lohnt es sich, den EXPLAIN-Plan auf beiden Systemen zu vergleichen.

6. GTID-Implementierungen im Vergleich

Global Transaction Identifiers (GTID) ermöglichen positionsunabhängige Replikation — eine der wichtigsten Funktionen für robuste Hochverfügbarkeits-Setups. Beide Systeme unterstützen GTID, implementieren das Format aber grundlegend verschieden, was die gegenseitige Kompatibilität ausschließt.

MySQL verwendet UUID-basierte GTIDs im Format source_id:transaction_id. Eine typische MySQL-GTID sieht so aus: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-23. Die UUID identifiziert den ursprünglichen Server, die Zahl den Transaktionsbereich.

MariaDB nutzt ein drei-teiliges Format: domain_id-server_id-sequence_number, zum Beispiel 0-1-100. Die domain_id erlaubt Multi-Domain-Replikation — verschiedene Replikationsdomänen können unabhängig voneinander operieren, was in komplexen Topologien (z.B. bidirektionale Replikation) erhebliche Flexibilität bietet.

-- MySQL 8: GTID-Status prüfen
SHOW MASTER STATUS\G
-- Ausgabe enthält: Executed_Gtid_Set: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100

-- MySQL: GTID-basierte Replikation einrichten
CHANGE MASTER TO
    MASTER_HOST = 'primary.example.com',
    MASTER_USER = 'replication',
    MASTER_PASSWORD = 'secret',
    MASTER_AUTO_POSITION = 1;

-- MariaDB: GTID-Status prüfen
SHOW MASTER STATUS\G
-- Ausgabe enthält: Gtid_binlog_pos: 0-1-100

-- MariaDB: GTID-Position für Replica setzen
SET GLOBAL gtid_slave_pos = '0-1-100';
CHANGE MASTER TO
    MASTER_HOST = 'primary.example.com',
    MASTER_USER = 'replication',
    MASTER_PASSWORD = 'secret',
    MASTER_USE_GTID = slave_pos;

-- MariaDB: Aktuelle GTID-Position lesen
SELECT @@global.gtid_current_pos;
SELECT @@global.gtid_binlog_pos;

Die GTID-Inkompatibilität bedeutet: Eine Replikation zwischen MySQL und MariaDB mit GTID ist nicht möglich. Wer zwischen den Systemen migrieren will, muss entweder auf positionsbasierte Replikation zurückgreifen oder mit einem sauberen Dump arbeiten.

7. Galera Cluster vs. InnoDB Cluster

Für Hochverfügbarkeit mit synchroner Multi-Master-Replikation bieten beide Systeme unterschiedliche Ansätze. MariaDB setzt auf Galera Cluster, eine synchrone Zertifizierungsbasierte Replikation, die seit Jahren in Produktion erprobt ist. MySQL bietet seit Version 8.0 InnoDB Cluster mit Group Replication.

Galera Cluster funktioniert auf Basis des Write-Set-Replikation (wsrep) API. Jede Transaktion wird bei COMMIT an alle Knoten gesendet und zertifiziert. Bei Konflikt wird die Transaktion auf dem schreibenden Knoten abgebrochen. Das Ergebnis ist echte synchrone Replikation ohne Replikationslag.

-- MariaDB Galera: Cluster-Status prüfen
SHOW STATUS LIKE 'wsrep_%';
-- Wichtige Variablen:
-- wsrep_cluster_size: Anzahl aktiver Knoten
-- wsrep_cluster_status: Primary / Non-Primary
-- wsrep_local_state_comment: Synced / Donor / Joiner
-- wsrep_flow_control_paused: Anteil der Zeit im Flow-Control (sollte nahe 0 sein)

SELECT VARIABLE_NAME, VARIABLE_VALUE
FROM information_schema.GLOBAL_STATUS
WHERE VARIABLE_NAME IN (
    'wsrep_cluster_size',
    'wsrep_cluster_status',
    'wsrep_local_state_comment',
    'wsrep_ready',
    'wsrep_flow_control_paused'
);

-- MySQL InnoDB Cluster: Group Replication Status
SELECT * FROM performance_schema.replication_group_members;

SELECT MEMBER_ID, MEMBER_HOST, MEMBER_STATE, MEMBER_ROLE
FROM performance_schema.replication_group_members;

InnoDB Cluster ist enger in das MySQL-Ökosystem integriert (MySQL Shell, MySQL Router, MySQL InnoDB ClusterSet) und bietet moderne Tooling-Unterstützung. Galera ist battle-tested, hat aber bekannte Probleme bei sehr langen Transaktionen und großen Write-Sets, da Flow-Control die Performance auf anderen Knoten drosseln kann.

8. performance_schema-Unterschiede

Beide Systeme bieten performance_schema für Laufzeitdiagnose, aber mit unterschiedlichem Umfang. MySQL 8 hat das performance_schema massiv ausgebaut — es enthält unter anderem detaillierte Statement-History, Variable-Settings, Error-Log-Zugriff und Memory-Instrumentation. MariaDB hat eine schlankere Implementierung, bietet dafür aber sys-Schema-Äquivalente und eigene Status-Variablen.

-- Langsamste Queries in MySQL 8 performance_schema
SELECT
    SCHEMA_NAME,
    DIGEST_TEXT,
    COUNT_STAR AS executions,
    ROUND(AVG_TIMER_WAIT / 1e9, 2) AS avg_ms,
    ROUND(MAX_TIMER_WAIT / 1e9, 2) AS max_ms,
    SUM_ROWS_EXAMINED,
    SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 20;

-- Memory-Nutzung in MySQL 8
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED / 1024 / 1024 AS mb_used
FROM performance_schema.memory_summary_global_by_event_name
WHERE CURRENT_NUMBER_OF_BYTES_USED > 0
ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC
LIMIT 15;

-- MariaDB: Äquivalente Analyse über Slow Query Log + Status
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Threads_connected';

9. Magento: Offiziell MySQL, praktisch MariaDB

Magento 2 wird offiziell mit MySQL 8.0 getestet und zertifiziert. MariaDB wird in den Systemanforderungen nicht explizit als unterstützt gelistet, funktioniert in der Praxis aber gut — mit einigen bekannten Caveats, die beim Betrieb berücksichtigt werden müssen.

Der wichtigste Punkt: Magento setzt auf sql_mode-Einstellungen, die auf beiden Systemen vorhanden sein müssen, aber leicht abweichen. Besonders ONLY_FULL_GROUP_BY kann bei bestimmten Magento-Queries auf MariaDB anders verhalten als auf MySQL. Außerdem hat MariaDB in bestimmten Versionen den Optimizer aggressiver konfiguriert, was zu unterschiedlichen Query-Plänen für komplexe EAV-Joins führen kann.

-- Magento-kompatiblen sql_mode auf beiden Systemen prüfen
SHOW VARIABLES LIKE 'sql_mode';

-- Empfohlener sql_mode für Magento (MySQL 8 und MariaDB)
-- Sicherstellen, dass diese Modi NICHT aktiv sind:
-- NO_ENGINE_SUBSTITUTION sollte aktiv sein
-- STRICT_TRANS_TABLES sollte aktiv sein

-- Auf MariaDB: Optimizer-Verhalten prüfen
SHOW VARIABLES LIKE 'optimizer_switch';

-- Potentielle Probleme mit GROUP BY auf MariaDB
-- (ONLY_FULL_GROUP_BY strenger in neueren MariaDB-Versionen)
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

-- InnoDB-Buffer-Pool auf beiden Systemen prüfen
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

-- Magento: Datenbankverbindung in env.php testet gegen diese Kompatibilität
-- MariaDB-spezifische Performance-Variable
SHOW VARIABLES LIKE 'aria_pagecache_buffer_size';

Ein weiterer praktischer Unterschied: Markt Shust's docker-magento verwendet standardmäßig MariaDB als Container-Image, obwohl die offizielle Magento-Dokumentation MySQL empfiehlt. Das spiegelt die Realität in vielen Entwicklungsumgebungen wider.

10. Migration zwischen MariaDB und MySQL

Eine Migration zwischen beiden Systemen ist grundsätzlich möglich, aber nicht trivial. Der einfachste Weg führt über mysqldump, da das SQL-Dump-Format weitgehend kompatibel ist. Problematisch werden jedoch Features, die nur auf einem System existieren: MariaDB-spezifische Syntax (SEQUENCE, FOR SYSTEM_TIME), MariaDB-eigene Storage Engines (Aria, Spider) oder MySQL-8-spezifische Features wie funktionale Indexe oder vollständige JSON-Path-Indizes.

-- Dump von MariaDB erstellen (für MySQL-Import optimiert)
-- mysqldump --single-transaction --routines --triggers \
--   --set-gtid-purged=OFF \
--   -h mariadb-host -u root -p magento_db > dump.sql

-- Vor dem Import auf MySQL: MariaDB-spezifische Syntax prüfen
-- grep -n "FOR SYSTEM_TIME\|CREATE SEQUENCE\|NEXTVAL\|LASTVAL" dump.sql

-- Inkompatibler CHARACTER SET prüfen
SHOW CREATE TABLE catalog_product_entity\G

-- utf8mb4 sicherstellen (beide Systeme unterstützen das)
ALTER TABLE catalog_product_entity CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- Nach Migration: Wichtige Variablen auf Zielsystem prüfen
SHOW VARIABLES LIKE 'character_set_%';
SHOW VARIABLES LIKE 'collation_%';
SHOW VARIABLES LIKE 'innodb_file_format';   -- nur MariaDB
SHOW VARIABLES LIKE 'innodb_default_row_format';

-- Tabellenstruktur auf Unterschiede prüfen
SELECT table_name, engine, row_format, table_collation
FROM information_schema.tables
WHERE table_schema = 'magento_db'
  AND engine NOT IN ('InnoDB', 'MEMORY')
ORDER BY table_name;

Ein oft übersehener Punkt bei Migrationen: Die Collation. Magento verwendet utf8mb4_unicode_ci, was auf beiden Systemen vorhanden ist. Neuere MariaDB-Versionen bieten jedoch utf8mb4_unicode_nopad_ci, das sich bei Vergleichen anders verhält. Nach einer Migration sollte man daher explizit alle Tabellen- und Spalten-Collations prüfen, bevor man den Shop in Betrieb nimmt.

12. Zusammenfassung

MariaDB vs. MySQL ist 2026 keine Frage von gut oder schlecht, sondern von bewusster Wahl und Kenntnis der Unterschiede. MySQL 8 bietet natives binäres JSON mit echter Performance-Optimierung, moderneres Tooling für InnoDB Cluster und ein aufgebohrtes performance_schema. MariaDB bringt SEQUENCE Engine, system-versioned Tables für automatische Historisierung, flexible GTID-Domains und battle-tested Galera Cluster.

Für Magento gilt: MySQL ist die offiziell getestete Variante, MariaDB funktioniert in der Praxis gut, erfordert aber Aufmerksamkeit bei sql_mode, Optimizer-Verhalten und JSON-Performance bei großen Dokumenten. Wer von einem System auf das andere migrieren will, muss mit dem GTID-Format-Unterschied umgehen und sollte system-versioned Tables sowie SEQUENCE-Objekte vorher identifizieren und migrieren.

13. FAQ: MariaDB vs. MySQL