MariaDB vs. MySQL: Spielt das für deine Website eine Rolle?

Rund 60 % der WordPress-Sites im Diagramm der Datenbankversionen von WordPress.org nutzen MariaDB, rund 40 % MySQL. WordPress läuft mit beiden: MariaDB 10.11 oder neuer oder MySQL 8.0 oder neuer. Die Engine unter deiner Site bemerkst du wahrscheinlich erst, wenn sie zu einem Host umzieht, der die andere nutzt.

Ein solcher Umzug kann an einer einzigen Zeile Fehlermeldung scheitern. Jemand, der von MySQL 8.0 nach MariaDB exportierte, bekam bei jedem Versuch Unknown collation utf8mb4_0900_ai_ci, und die zugehörige Frage auf Stack Exchange hat 74.574 Aufrufe. Auf unserem Testserver (kein DreamHost-Server) scheiterte der umgekehrte Umzug genauso. Eine Tabelle mit der Standard-Collation von MariaDB 11.8 stoppte einen Import in MySQL 8.4 mit Unknown collation: 'utf8mb4_uca1400_ai_ci', während eine WordPress-Datenbank in beide Richtungen problemlos umzog.

Welche Engine bei welchem DreamHost-Tarif läuft

Alle DreamHost-Tarife, bei denen wir die Datenbank für dich betreiben, nutzen MySQL. Die Versionstabelle im Help Center von DreamHost nennt 8.0 für Shared MySQL und 8.0 oder 8.4 für dedizierte Server, je nach Ubuntu-Release. Die Seite zu MySQL VPS nennt MySQL 8.0. Mit der Abfrage unten siehst du, was bei dir läuft.

Ein verwaltetes VPS speichert deine Datenbanken auf den Shared-MySQL-Servern von DreamHost und folgt daher der Zeile für Shared Hosting. Auf einem dedizierten Server kannst du laut der MySQL-Übersicht im Help Center von DreamHost außerdem jede beliebige MySQL-Version installieren.

Wenn deine App beim Shared Hosting MySQL 8.4 braucht, bevor dein Server umgestellt wird, lautet die Antwort im Help Center: Füge ein MySQL VPS hinzu und zieh deine Datenbanken dorthin um. Bevor du eins hinzufügst, prüfe, ob deine Datenbank deine Site ausbremst, und wenn du auch eine Cloud-Datenbank in Betracht ziehst, vergleiche die Preise von RDS for MySQL mit einem privaten MySQL-Server.

So prüfst du deine Version

1. phpMyAdmin öffnen
   Melde dich über dein DreamHost-Panel bei phpMyAdmin an oder über die Tools deines eigenen Servers.
2. Auf den SQL-Tab klicken
   Es öffnet sich ein Feld, in das du eine Abfrage an den Server eingeben kannst.
3. Versionsabfrage ausführen

   Füge das ein und führe es aus:

   sqlKopieren

   SELECT VERSION();

   Ein MySQL-Server antwortet mit einer einfachen Nummer wie 8.4.11. Ein MariaDB-Server nennt in der Antwort seinen Namen, unserer lieferte 11.8.9-MariaDB-ubu2404.

Auf einem VPS, das du selbst einrichtest, entscheidet das Linux-Release, was du mit apt install bekommst. Ubuntu 24.04 liefert MySQL 8.0 und MariaDB 10.11. Ubuntu 26.04 liefert MySQL 8.4 und MariaDB 11.8. Debian 13 hat MariaDB 11.8 und gar kein MySQL-Serverpaket, und sein Paket default-mysql-server installiert MariaDB. Unser Test hat das bestätigt und gezeigt, dass default-mysql-server unter Ubuntu den umgekehrten Weg geht: Es installiert MySQL, 8.4 unter 26.04 und 8.0 unter 24.04. Auf unserem LAMP Stack VPS zeigt dir dieselbe Abfrage, welche MariaDB-Version du hast. Wenn du dich noch nicht für ein Linux entschieden hast, vergleicht unser Ratgeber Welches Linux auf deinem VPS? die vier, die wir anbieten.

Was MySQL 8.4 und MariaDB 11.8 unterscheidet

MariaDB stammt von den ursprünglichen Entwicklern von MySQL. Die beiden haben sich auseinanderentwickelt, und die eigene Liste der Unterschiede von MariaDB ist lang. Das hier sind die Punkte, auf die du als Site-Betreiber stoßen kannst.

Auf die Collation-Zeile stößt du höchstwahrscheinlich zuerst. MySQL 8 versieht neue Textspalten mit utf8mb4_0900_ai_ci, MariaDB 11.4 und neuer verwenden laut der Kompatibilitätsmatrix von MariaDB utf8mb4_uca1400_ai_ci. Ein Export trägt diese Namen in jeder CREATE TABLE-Zeile. Laut der Liste der Unterschiede von MariaDB kennt 11.8 insgesamt 550 Collations, darunter 44 Aliase, die in 11.4.5 hinzukamen, um die Replikation von MySQL zu erleichtern. In unserem Test übernahm MariaDB 11.8 eine mit utf8mb4_0900_ai_ci versehene Tabelle aus MySQL 8.4 ohne Beanstandung. Umgekehrt scheiterte es, weil MySQL 8.4 utf8mb4_uca1400_ai_ci nicht kennt, und der Import brach mit ERROR 1273 ab. WordPress stößt auf keines der beiden Probleme. Es legte auf beiden Engines jede Tabelle als utf8mb4_unicode_520_ci an.

Die Werkseinstellungen spielen eine Rolle, wenn du die beiden selbst vergleichst. MySQL 8.4 aktiviert die binäre Protokollierung von Haus aus, MariaDB lässt sein Binärlog ausgeschaltet. Beim Performance Schema ist es genauso: in MySQL an, in MariaDB 11.8 aus. Ein direkter Vergleich, der beide unverändert lässt, vergleicht ebenso sehr zwei Konfigurationsdateien wie zwei Engines, deshalb haben wir unseren Test in beiden Varianten durchgeführt.

Arbeitsspeicher, Geschwindigkeit und Speicherplatz auf unserem Testserver

Ohne Verbindungen lag MySQL bei 427 MiB Arbeitsspeicher und MariaDB bei 137 MiB. Wir haben die offiziellen Images von MySQL 8.4.11 und MariaDB 11.8.9 nacheinander auf einer Test-VM mit 2 vCPU und 4 GB Arbeitsspeicher ausgeführt, also in der Größe unseres Tarifs Stack 4.

Bei der Geschwindigkeit lagen die beiden etwa gleichauf, sobald die Einstellungen angeglichen waren. Jede Engine lief den Benchmark einmal pro Einstellung – zu wenige Durchläufe, um eine davon als schneller zu bezeichnen.

Den Unterschied beim Arbeitsspeicher spürst du auf einem kleinen Server, auf dem sich die Datenbank den RAM mit PHP und deinem Webserver teilt. Von den 3.904 MB unserer Test-VM waren mit MariaDB im Leerlauf noch 3.465 MB verfügbar, mit MySQL 3.136 MB. Direkt nach dem Benchmark schrumpfte der Abstand von MySQL zu MariaDB von 356 MiB auf 101 MiB, nachdem wir die beiden ab Werk aktiven Extras von MySQL abgeschaltet hatten. Wie du einen Datenbankserver dimensionierst, erfährst du unter Wie viel RAM braucht MySQL?.

Spielt es für deine App eine Rolle?

Wir haben WordPress 7.1.3 auf jeder Engine installiert, 200 Beiträge und 500 Kommentare erzeugt und die Startseite auf beiden fehlerfrei geladen. Den Apps in der Tabelle unten geht es genauso: Prüf die Anforderungsseite deiner App, bevor du dir Gedanken über die Engine machst – dort findest du meist beide mit einer Mindestversion. Die Angaben stammen von der jeweiligen Seite der App, abgerufen am 16. Oktober 2026.

Ghost ist hier die einzige App, für die es eine Rolle spielt. Ihre Seite zu unterstützten Datenbanken sagt, dass MySQL 8 die einzige im Produktivbetrieb unterstützte Datenbank ist, und empfiehlt dringend, von MariaDB wegzuwechseln, falls du es nutzt.

Auch Nextcloud 35 verdient einen zweiten Blick. Seine Anforderungen nennen MySQL 8.4 und 9.7, 8.0 dagegen nicht. Auf einem Server, den du selbst betreibst, nutzt du MySQL 8.4 oder eine der dort aufgeführten MariaDB-Versionen.

Eine Datenbank zwischen beiden umziehen

Um eine Datenbank in eine der beiden Richtungen zwischen MySQL und MariaDB umzuziehen, exportierst du sie in eine SQL-Datei und importierst diese. Der Migrationsleitfaden von MariaDB beantwortet die Frage Can I perform an in-place upgrade? für alle, die von MySQL 8.0 oder 8.4 kommen, mit einem klaren No. Die Dateien einfach rüberzukopieren funktioniert nicht.

1. Version auf beiden Servern prüfen
   Führe SELECT VERSION(); auf dem alten und dem neuen Server aus. Wenn du weißt, welche Engine du verlässt, weißt du auch, nach welchen Collation-Namen du in Schritt 3 suchen musst.
2. Mit dem Tool des alten Servers exportieren

   Nutze bei MySQL das mysqldump von MySQL. Der Migrationsleitfaden von MariaDB verlangt das, da das eigene mariadb-dump von MariaDB kaum mit MySQL getestet wurde. Bei MariaDB nutzt du mariadb-dump. Gib eine einzelne Datenbank an und lass --databases weg, damit die Datei keine CREATE DATABASE-Zeile enthält:

   bashKopieren

   mysqldump --user=USER \
     --password \
     --single-transaction \
     --routines --triggers \
     --hex-blob \
     DBNAME > site.sql

   Der Artikel zu Importfehlern von DreamHost erklärt, dass eine CREATE DATABASE-Zeile den Import mit ERROR 1044 scheitern lässt. Wenn du zu DreamPress umziehst, lass --routines und --triggers weg, weil die MySQL-Server von DreamPress keine Stored Routines oder Trigger unterstützen.

3. Collation-Namen ersetzen, die der neue Server nicht kennt
   Bei einer WordPress-Datenbank kannst du diesen Schritt meist überspringen, da WordPress in unserem Test auf beiden Engines utf8mb4_unicode_520_ci verwendet hat und problemlos in beide Richtungen umzog. Tabellen mit der Standard-Collation des Servers können in einer Richtung scheitern. MySQL 8.4 brach bei Unknown collation: 'utf8mb4_uca1400_ai_ci' in einem Export aus MariaDB 11.8 ab, während MariaDB 11.8 das utf8mb4_0900_ai_ci von MySQL akzeptierte. Ältere MariaDB-Versionen lehnen es ab, wie in der Frage auf Stack Exchange. Ersetze den unbekannten Namen in der gesamten Datei durch utf8mb4_unicode_520_ci, das beide Engines kennen, und importiere erneut. Das ist die Lösung aus den besten Antworten auf Stack Exchange, und es ist die Collation, die WordPress in unserem Test auf beiden Engines gewählt hat.
4. In eine leere Datenbank importieren
   Lege zuerst die Datenbank und ihren Benutzer in deinem Panel an und importiere die Datei dann in phpMyAdmin oder mit dem Client mysql. In unserem Test legten Dumps von mysqldump und mariadb-dump ihren eigenen Zeichensatz fest. Wenn du eine von Hand geschriebene SQL-Datei per Pipe an den Client mysql im offiziellen MySQL-Docker-Image übergibst, füge --default-character-set=utf8mb4 hinzu: Ohne diese Option fiel der Client in unserem Test auf latin1 zurück und verstümmelte Buchstaben mit Akzenten.
5. Website testen, bevor du das DNS umstellst
   Lade ein paar Seiten, melde dich im Admin-Bereich an, führe eine Suche aus und speichere einen Beitrag.

Welche du wählen solltest

Unsere Empfehlung für eine PHP-Site: die Engine, die dein Host bereits nutzt, auf einer unterstützten Version.

Wenn du MySQL 8.0 nutzt, ist MySQL 8.4 dein nächster Schritt, und dafür kannst du bei MySQL bleiben. Oracle hat MySQL 8.0 am 21. April 2026 in den Sustaining Support überführt und empfiehlt ein Upgrade auf 8.4 oder 9.7. Laut Help Center von DreamHost werden dedizierte Server bereits auf 8.4 umgestellt, Shared-Server folgen nach dem Zeitplan von DreamHost, und Kunden mit MySQL VPS können das Upgrade beim Support anfragen.

Wie wir gemessen haben

Wir haben den Test am 19. Oktober 2026 auf einer VM unter Colima auf einem Apple-M2-Mac durchgeführt: arm64, 2 vCPU, 3.904 MB sichtbarer Arbeitsspeicher, kein Swap, Ubuntu 24.04.4 und Docker 29.5.2. Einen DreamHost-Server haben wir nicht verwendet. Wir haben die offiziellen Images mysql:8.4.11 und mariadb:11.8.9 genutzt, per Digest fixiert, und für die Läufe im Auslieferungszustand nichts verändert. Der Speicher im Leerlauf ist der Median aus 12 Messungen mit docker stats im Abstand von 5 Sekunden nach einer Einschwingzeit von 2 Minuten; 10 Minuten später hatte sich der Wert nicht verändert. Als Benchmark diente der oltp_read_write-Test von sysbench 1.0.20 mit 4 Tabellen à 100.000 Zeilen, die in den standardmäßigen 128-MB-Buffer-Pool jeder Engine passen, 4 Threads, 60 Sekunden Aufwärmphase und dann ein Lauf von 120 Sekunden pro Engine und Einstellung.

Unsere VPS und dedizierten Server nutzen AMD-EPYC-Prozessoren. Vergleiche die Engines dort also anhand des Verhältnisses und erwarte nicht dieselben absoluten Werte. Ein MySQL VPS, Shared MySQL und unser LAMP-Stack-Image waren nicht Teil des Tests. Jeder Benchmark lief nur einmal, mit synthetischen Daten, die einfacher sind als der Traffic einer echten Website. Beim Lauf von MariaDB wurden zudem 683 Fehler protokolliert, die sysbench wiederholt und separat zählt (etwa 6 pro Sekunde), bei MySQL keine; den Grund haben wir nicht untersucht. Der WordPress-Check umfasste die Installation, generierte Inhalte und Seitenaufrufe, und für jeden Umzug kam das eigene Dump-Tool der Quell-Engine zum Einsatz.

FAQ zu MySQL und MariaDB