MariaDB vs MySQL: maakt het uit voor je site?

Ongeveer 60% van de WordPress-sites in de grafiek met databaseversies van WordPress.org draait op MariaDB, en ongeveer 40% op MySQL. WordPress accepteert allebei: MariaDB 10.11 of later, of MySQL 8.0 of later. Je merkt waarschijnlijk pas welke engine onder je site draait als je site verhuist naar een host die de andere gebruikt.

Zo'n verhuizing kan vastlopen op één regel foutmelding. Iemand die van MySQL 8.0 naar MariaDB exporteerde, kreeg bij elke poging Unknown collation utf8mb4_0900_ai_ci, en die vraag op Stack Exchange is 74.574 keer bekeken. Op onze testserver (geen server van DreamHost) mislukte de omgekeerde verhuizing op dezelfde manier. Een tabel die met de standaardcollatie van MariaDB 11.8 was gemaakt, bracht een import in MySQL 8.4 tot stilstand met Unknown collation: 'utf8mb4_uca1400_ai_ci', terwijl een WordPress-database in beide richtingen probleemloos overging.

Welke engine elk DreamHost-pakket gebruikt

Elk DreamHost-abonnement waarbij wij de database voor je beheren, gebruikt MySQL. De versietabel in het Help Center van DreamHost noemt 8.0 voor gedeelde MySQL en 8.0 of 8.4 voor Dedicated, afhankelijk van de Ubuntu-release. De MySQL VPS-pagina noemt MySQL 8.0. Met de query hieronder zie je wat er bij jou draait.

Een beheerde VPS houdt je databases op de gedeelde MySQL-servers van DreamHost, dus daarvoor geldt de rij voor gedeelde hosting. Met het Dedicated-abonnement kun je bovendien elke gewenste MySQL-versie installeren, volgens het MySQL-overzicht in het Help Center van DreamHost.

Heb je op gedeelde hosting MySQL 8.4 nodig voordat je server overgaat, dan adviseert het Help Center om een MySQL VPS toe te voegen en je databases daarnaartoe te verhuizen. Kijk voordat je er een toevoegt eerst of je database je site vertraagt, en als je ook de prijs van een clouddatabase bekijkt: de prijzen van RDS for MySQL naast een eigen MySQL-server.

Zo controleer je de jouwe

1. Open phpMyAdmin
   Log in op phpMyAdmin via je DreamHost-panel of via de tools van je eigen server.
2. Klik op het tabblad SQL
   Er opent een venster waarin je een query op de server kunt uitvoeren.
3. Voer de versiequery uit

   Plak dit en voer het uit:

   sqlKopiëren

   SELECT VERSION();

   Een MySQL-server antwoordt met alleen een getal, zoals 8.4.11. Een MariaDB-server noemt zijn eigen naam in het antwoord, en de onze gaf 11.8.9-MariaDB-ubu2404.

Op een VPS die je zelf inricht, bepaalt de Linux-release wat apt install je geeft. Ubuntu 24.04 levert MySQL 8.0 en MariaDB 10.11. Ubuntu 26.04 levert MySQL 8.4 en MariaDB 11.8. Debian 13 heeft MariaDB 11.8 en helemaal geen MySQL-serverpakket, en het pakket default-mysql-server installeert daar MariaDB. Onze test bevestigde dat, en liet zien dat default-mysql-server op Ubuntu precies andersom werkt: het installeert MySQL, 8.4 op 26.04 en 8.0 op 24.04. Op onze LAMP Stack VPS vertelt dezelfde query welke MariaDB-versie je hebt gekregen. Heb je nog geen Linux gekozen, dan vergelijkt onze gids over welke Linux je op je VPS draait de vier die we aanbieden.

Wat er verschilt tussen MySQL 8.4 en MariaDB 11.8

MariaDB wordt gemaakt door de oorspronkelijke ontwikkelaars van MySQL. De twee zijn uit elkaar gegroeid, en de eigen lijst met verschillen van MariaDB is lang. Dit zijn de punten waar je als site-eigenaar tegenaan kunt lopen.

Je komt waarschijnlijk als eerste de collatierij tegen. MySQL 8 geeft nieuwe tekstkolommen utf8mb4_0900_ai_ci mee, en MariaDB 11.4 en later gebruiken utf8mb4_uca1400_ai_ci, volgens de compatibiliteitsmatrix van MariaDB. Een export neemt die namen mee in elke CREATE TABLE-regel. Volgens de lijst met verschillen van MariaDB kent 11.8 550 collaties, waaronder 44 aliassen die in 11.4.5 zijn toegevoegd om replicatie vanuit MySQL te vergemakkelijken. In onze test accepteerde MariaDB 11.8 zonder klagen een MySQL 8.4-tabel met utf8mb4_0900_ai_ci. Andersom mislukte het, omdat MySQL 8.4 utf8mb4_uca1400_ai_ci niet kent, en de import stopte met ERROR 1273. WordPress loopt tegen geen van beide problemen aan. Het maakte op beide engines elke tabel aan als utf8mb4_unicode_520_ci.

De standaardinstellingen doen ertoe als je de twee zelf vergelijkt. MySQL 8.4 zet binaire logging standaard aan, en MariaDB laat zijn binaire log uit. Performance Schema volgt dezelfde verdeling: aan in MySQL, uit in MariaDB 11.8. Een vergelijkingstest die beide ongemoeid laat, vergelijkt evengoed twee configuratiebestanden als twee engines, dus we hebben de onze op beide manieren gedraaid.

Geheugen, snelheid en schijfruimte op onze testserver

Zonder verbindingen gebruikte MySQL 427 MiB geheugen en MariaDB 137 MiB. We draaiden de officiële images van MySQL 8.4.11 en MariaDB 11.8.9 een voor een op een test-VM met 2 vCPU en 4 GB geheugen, even groot als ons Stack 4-abonnement.

Qua snelheid kwamen de twee ongeveer gelijk uit zodra de instellingen overeenkwamen. Elke engine draaide de benchmark één keer per instelling, te weinig om een van beide sneller te noemen.

Het geheugenverschil merk je op een kleine server, waar de database het RAM deelt met PHP en je webserver. Van de 3.904 MB van onze test-VM was nog 3.465 MB beschikbaar met MariaDB in rust en 3.136 MB met MySQL. Direct na de benchmark kromp het verschil tussen MySQL en MariaDB van 356 MiB naar 101 MiB toen we de twee standaard ingeschakelde extra's van MySQL uitzetten. Wil je een databaseserver dimensioneren, lees dan hoeveel RAM MySQL nodig heeft.

Maakt het jouw app uit?

We installeerden WordPress 7.1.3 op beide engines, genereerden 200 berichten en 500 reacties, en laadden de homepage op allebei zonder fout. De apps in de tabel hieronder werken net zo: kijk op de pagina met systeemeisen van je app voordat je over de engine nadenkt, en je vindt er meestal allebei met een minimale versie. Deze gegevens komen van de eigen pagina van elke app, gelezen op 16 oktober 2026.

Ghost is de enige app hier waarvoor het uitmaakt. Op de pagina met ondersteunde databases van Ghost staat dat MySQL 8 de enige ondersteunde database in productie is, en Ghost raadt sterk aan om van MariaDB af te stappen als je dat gebruikt.

Ook Nextcloud 35 verdient een tweede blik. De systeemeisen noemen MySQL 8.4 en 9.7 en laten 8.0 weg. Op een server die je zelf beheert, gebruik je MySQL 8.4 of een van de vermelde MariaDB-versies.

Een database tussen de twee verhuizen

Om een database in welke richting dan ook tussen MySQL en MariaDB te verhuizen, exporteer je die naar een SQL-bestand en importeer je dat bestand. De migratiegids van MariaDB beantwoordt de vraag Can I perform an in-place upgrade? met een kort No voor iedereen die van MySQL 8.0 of 8.4 komt. Je kunt de bestanden niet zomaar overzetten.

1. Controleer de versie op beide servers
   Voer SELECT VERSION(); uit op de oude en de nieuwe server. Als je weet welke engine je verlaat, weet je naar welke collatienamen je in stap 3 moet zoeken.
2. Exporteer met de eigen tool van de oude server

   Gebruik op MySQL de mysqldump van MySQL. De migratiegids van MariaDB vraagt daarom, omdat de eigen mariadb-dump van MariaDB nog weinig tegen MySQL is getest. Gebruik op MariaDB mariadb-dump. Geef één database op en laat --databases weg, zodat het bestand geen CREATE DATABASE-regel bevat:

   bashKopiëren

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

   Het artikel over importfouten van DreamHost legt uit dat een CREATE DATABASE-regel de import laat mislukken met ERROR 1044. Verhuis je naar DreamPress, laat dan --routines en --triggers weg, want de MySQL-servers van DreamPress ondersteunen geen opgeslagen routines of triggers.

3. Vervang collatienamen die de nieuwe server niet kent
   Een WordPress-database kan deze stap meestal overslaan, want WordPress gebruikte in onze test op beide engines utf8mb4_unicode_520_ci en verhuisde zonder fouten in beide richtingen. Tabellen met de standaardcollatie van de server kunnen in één richting mislukken. MySQL 8.4 stopte bij Unknown collation: 'utf8mb4_uca1400_ai_ci' in een export van MariaDB 11.8, terwijl MariaDB 11.8 de utf8mb4_0900_ai_ci van MySQL accepteerde. Oudere MariaDB-versies weigeren die, zoals in de vraag op Stack Exchange. Vervang de onbekende naam overal in het bestand door utf8mb4_unicode_520_ci, die beide engines kennen, en importeer opnieuw. Dat is de oplossing uit de beste antwoorden op Stack Exchange, en het is de collatie die WordPress in onze test op beide engines koos.
4. Importeer in een lege database
   Maak eerst de database en de bijbehorende gebruiker aan in je panel en importeer het bestand daarna in phpMyAdmin of met de mysql-client. In onze test stelden dumps van mysqldump en mariadb-dump zelf hun tekenset in. Stuur je een zelfgeschreven SQL-bestand via een pipe naar de mysql-client in de officiële MySQL Docker-image, voeg dan --default-character-set=utf8mb4 toe: zonder die optie viel die client in onze test terug op latin1 en raakten letters met accenten verminkt.
5. Test de site voordat je DNS omzet
   Laad een paar pagina's, log in op het beheergedeelte, voer een zoekopdracht uit en sla een bericht op.

Welke kies je?

Onze keuze voor een PHP-site: de engine die je host al draait, op een ondersteunde versie.

Gebruik je MySQL 8.0? Dan is MySQL 8.4 je volgende stap, en daarvoor kun je gewoon bij MySQL blijven. Oracle heeft MySQL 8.0 op 21 april 2026 naar Sustaining Support verplaatst en raadt gebruikers aan te upgraden naar 8.4 of 9.7. Volgens het Help Center van DreamHost stappen dedicated servers al over op 8.4 en volgen gedeelde servers het eigen schema van DreamHost. Klanten met een MySQL VPS kunnen contact opnemen met support om de upgrade aan te vragen.

Hoe we hebben gemeten

We voerden de test uit op 19 oktober 2026, op een VM onder Colima op een Apple M2 Mac: arm64, 2 vCPU's, 3.904 MB zichtbaar geheugen, geen swap, Ubuntu 24.04.4 en Docker 29.5.2. We gebruikten geen server van DreamHost. We gebruikten de officiële images mysql:8.4.11 en mariadb:11.8.9, vastgezet op digest, en veranderden niets voor de runs met standaardinstellingen. Het geheugen in rust is de mediaan van 12 metingen met docker stats, genomen met 5 seconden ertussen na een stabilisatieperiode van 2 minuten. 10 minuten later was die waarde niet veranderd. De benchmark was de oltp_read_write-test van sysbench 1.0.20 met 4 tabellen van 100.000 rijen, die in de standaard bufferpool van 128 MB van elke engine passen. We gebruikten 4 threads en een opwarmperiode van 60 seconden, gevolgd door één run van 120 seconden per engine en instelling.

Onze VPS- en dedicated servers gebruiken AMD EPYC-processors. Vergelijk de engines daar dus op verhouding en verwacht niet dezelfde absolute cijfers. We hebben geen MySQL VPS, gedeelde MySQL of ons LAMP Stack-image getest. Elke benchmark draaide één keer, op synthetische data die eenvoudiger is dan het verkeer van een echte site. De run van MariaDB registreerde ook 683 fouten die sysbench opnieuw probeert en apart telt (ongeveer 6 per seconde), terwijl die van MySQL er geen registreerde. Waarom dat zo is, hebben we niet onderzocht. De WordPress-controle omvatte de installatie, gegenereerde content en het laden van pagina's, en bij elke verhuizing gebruikten we de eigen dumptool van de bronengine.

Veelgestelde vragen over MySQL en MariaDB