MariaDB ou MySQL : quel impact pour votre site ?

Environ 60 % des sites WordPress recensés dans le graphique des versions de base de données de WordPress.org utilisent MariaDB, et environ 40 % utilisent MySQL. WordPress accepte l'un ou l'autre : MariaDB 10.11 ou version ultérieure, ou MySQL 8.0 ou version ultérieure. Vous ne remarquerez sans doute pas le moteur qui fait tourner votre site, jusqu'au jour où il est transféré chez un hébergeur qui utilise l'autre.

Une migration de ce type peut buter sur une seule ligne de message d'erreur. Une personne qui exportait de MySQL 8.0 vers MariaDB obtenait Unknown collation utf8mb4_0900_ai_ci à chaque tentative, et sa question sur Stack Exchange compte 74 574 vues. Sur notre serveur de test (qui n'est pas un serveur DreamHost), la migration inverse a échoué de la même façon. Une table créée avec la collation par défaut de MariaDB 11.8 a bloqué une importation dans MySQL 8.4 avec Unknown collation: 'utf8mb4_uca1400_ai_ci', alors qu'une base de données WordPress a migré sans problème dans les deux sens.

Le moteur utilisé par chaque offre DreamHost

Tous les forfaits DreamHost pour lesquels nous gérons la base de données à votre place utilisent MySQL. Le tableau des versions du centre d'aide de DreamHost indique 8.0 pour MySQL en hébergement partagé, et 8.0 ou 8.4 pour les serveurs dédiés, selon la version d'Ubuntu. La page MySQL VPS indique MySQL 8.0. La requête ci-dessous vous montre la version de votre serveur.

Le VPS géré conserve vos bases de données sur les serveurs MySQL partagés de DreamHost : il suit donc la ligne de l'hébergement partagé. Avec un serveur dédié, vous pouvez aussi installer la version de MySQL de votre choix, selon la présentation de MySQL du centre d'aide de DreamHost.

En hébergement partagé, si votre application a besoin de MySQL 8.4 avant la migration de votre serveur, le centre d'aide recommande d'ajouter un MySQL VPS et d'y transférer vos bases de données. Avant d'en ajouter un, vérifiez si votre base de données ralentit votre site et, si vous comparez aussi les prix d'une base de données cloud, consultez les tarifs de RDS for MySQL face à ceux d'un serveur MySQL privé.

Comment vérifier le vôtre

1. Ouvrez phpMyAdmin
   Connectez-vous à phpMyAdmin depuis votre panel DreamHost, ou depuis les outils de votre propre serveur.
2. Cliquez sur l'onglet SQL
   Une zone s'ouvre, dans laquelle vous pouvez saisir une requête à exécuter sur le serveur.
3. Lancez la requête de version

   Collez ceci et exécutez-le :

   sqlCopier

   SELECT VERSION();

   Un serveur MySQL répond par un simple numéro, comme 8.4.11. Un serveur MariaDB indique son nom dans la réponse ; le nôtre a renvoyé 11.8.9-MariaDB-ubu2404.

Sur un VPS que vous configurez vous-même, c'est la version de Linux qui détermine ce que vous obtenez avec apt install. Ubuntu 24.04 fournit MySQL 8.0 et MariaDB 10.11. Ubuntu 26.04 fournit MySQL 8.4 et MariaDB 11.8. Debian 13 propose MariaDB 11.8 et aucun paquet de serveur MySQL, et son paquet default-mysql-server installe MariaDB. Notre test l'a confirmé, et il a montré que le paquet default-mysql-server d'Ubuntu fait l'inverse : il installe MySQL, en 8.4 sous 26.04 et en 8.0 sous 24.04. Sur notre LAMP Stack VPS, la même requête vous indique quelle version de MariaDB vous avez obtenue. Si vous n'avez pas encore choisi votre distribution Linux, notre guide sur la distribution Linux à utiliser sur votre VPS compare les quatre que nous proposons.

Les différences entre MySQL 8.4 et MariaDB 11.8

MariaDB est développé par les développeurs d'origine de MySQL. Les deux se sont éloignés au fil du temps, et la liste des différences publiée par MariaDB est longue. Voici les points auxquels le propriétaire d'un site peut être confronté.

Vous croiserez très probablement la ligne des collations en premier. MySQL 8 attribue utf8mb4_0900_ai_ci aux nouvelles colonnes de texte, et MariaDB 11.4 et versions ultérieures utilisent utf8mb4_uca1400_ai_ci, selon la matrice de compatibilité de MariaDB. Un export reprend ces noms dans chaque ligne CREATE TABLE. D'après la liste des différences de MariaDB, la version 11.8 connaît 550 collations, dont 44 alias ajoutés dans la 11.4.5 pour faciliter la réplication depuis MySQL. Lors de notre test, MariaDB 11.8 a accepté sans broncher une table MySQL 8.4 marquée utf8mb4_0900_ai_ci. L'inverse a échoué, car MySQL 8.4 ne connaît pas utf8mb4_uca1400_ai_ci, et l'importation s'est arrêtée avec ERROR 1273. WordPress ne rencontre aucun de ces problèmes : il a créé toutes les tables en utf8mb4_unicode_520_ci sur les deux moteurs.

Les réglages par défaut comptent si vous comparez les deux vous-même. MySQL 8.4 active la journalisation binaire dès l'installation, alors que MariaDB laisse son journal binaire désactivé. Performance Schema suit la même logique : activé dans MySQL, désactivé dans MariaDB 11.8. Un test comparatif qui ne touche à aucun des deux compare autant deux fichiers de configuration que deux moteurs : nous avons donc mené le nôtre dans les deux configurations.

Mémoire, vitesse et disque sur notre serveur de test

Sans aucune connexion, MySQL occupait 427 Mio de mémoire et MariaDB 137 Mio. Nous avons exécuté les images officielles MySQL 8.4.11 et MariaDB 11.8.9 l'une après l'autre sur une VM de test dotée de 2 vCPU et de 4 Go de mémoire, soit la même taille que notre forfait Stack 4.

Côté vitesse, les deux se sont révélés à peu près équivalents une fois les réglages alignés. Chaque moteur a exécuté le benchmark une seule fois par configuration, ce qui est trop peu pour déclarer l'un plus rapide que l'autre.

L'écart de mémoire se ferait sentir sur un petit serveur, où la base de données partage la RAM avec PHP et votre serveur web. Sur les 3 904 Mo de notre VM de test, 3 465 Mo restaient disponibles avec MariaDB au repos, contre 3 136 Mo avec MySQL. Juste après le benchmark, désactiver les deux options activées par défaut dans MySQL a réduit son écart avec MariaDB de 356 Mio à 101 Mio. Pour dimensionner un serveur de base de données, découvrez de combien de RAM MySQL a besoin.

Votre application est-elle concernée ?

Nous avons installé WordPress 7.1.3 sur chaque moteur, généré 200 articles et 500 commentaires, puis chargé la page d'accueil sans aucune erreur, sur l'un comme sur l'autre. Les applications du tableau ci-dessous sont dans le même cas : consultez la page des exigences de votre application avant de vous soucier du moteur, et vous y trouverez généralement les deux, chacun avec une version minimale. Ces informations proviennent de la page de chaque application, consultée le 16 octobre 2026.

Ghost est la seule application de cette liste pour laquelle le choix compte. Sa page sur les bases de données prises en charge indique que MySQL 8 est la seule base de données prise en charge en production, et recommande vivement de quitter MariaDB si vous l'utilisez.

Nextcloud 35 mérite aussi qu'on s'y attarde. Ses exigences mentionnent MySQL 8.4 et 9.7, mais pas la 8.0. Sur un serveur que vous gérez vous-même, utilisez MySQL 8.4 ou l'une des versions de MariaDB qu'il cite.

Migrer une base de données de l'un à l'autre

Pour déplacer une base de données entre MySQL et MariaDB, dans un sens comme dans l'autre, vous l'exportez dans un fichier SQL, puis vous importez ce fichier. Le guide de migration de MariaDB répond à la question « Can I perform an in-place upgrade? » par un simple « No » pour quiconque vient de MySQL 8.0 ou 8.4. Vous ne pouvez pas copier les fichiers d'un serveur à l'autre.

1. Vérifiez la version sur les deux serveurs
   Exécutez SELECT VERSION(); sur l'ancien serveur et sur le nouveau. Savoir quel moteur vous quittez vous indique quels noms de collation rechercher à l'étape 3.
2. Exportez avec l'outil de l'ancien serveur

   Sous MySQL, utilisez le mysqldump de MySQL. Le guide de migration de MariaDB le demande, car le mariadb-dump de MariaDB a été peu testé avec MySQL. Sous MariaDB, utilisez mariadb-dump. Indiquez une seule base de données et omettez --databases, pour que le fichier ne contienne aucune ligne CREATE DATABASE :

   bashCopier

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

   L'article sur les erreurs d'importation de DreamHost explique qu'une ligne CREATE DATABASE fait échouer l'importation avec ERROR 1044. Si vous migrez vers DreamPress, omettez --routines et --triggers, car les serveurs MySQL de DreamPress ne prennent en charge ni les procédures stockées ni les déclencheurs.

3. Remplacez les noms de collation inconnus du nouveau serveur
   Avec une base de données WordPress, vous pouvez généralement sauter cette étape : lors de notre test, WordPress a utilisé utf8mb4_unicode_520_ci sur les deux moteurs et a migré dans les deux sens sans erreur. Les tables qui utilisent la collation par défaut du serveur peuvent échouer dans un sens. MySQL 8.4 s'est arrêté sur Unknown collation: 'utf8mb4_uca1400_ai_ci' dans un export MariaDB 11.8, alors que MariaDB 11.8 a accepté le utf8mb4_0900_ai_ci de MySQL. Les versions plus anciennes de MariaDB le rejettent, comme dans la question sur Stack Exchange. Remplacez le nom inconnu dans tout le fichier par utf8mb4_unicode_520_ci, que les deux moteurs connaissent, puis relancez l'importation. C'est la solution retenue par les réponses les mieux notées sur Stack Exchange, et c'est la collation que WordPress a choisie sur les deux moteurs lors de notre test.
4. Importez dans une base de données vide
   Créez d'abord la base de données et son utilisateur dans votre panel, puis importez le fichier dans phpMyAdmin ou avec le client mysql. Lors de notre test, les dumps générés par mysqldump et mariadb-dump définissaient leur propre jeu de caractères. Si vous envoyez un fichier SQL écrit à la main vers le client mysql dans l'image Docker officielle de MySQL, ajoutez --default-character-set=utf8mb4 : sans cette option, ce client est revenu au latin1 lors de notre test et a altéré les lettres accentuées.
5. Testez le site avant de basculer le DNS
   Chargez quelques pages, connectez-vous à l'administration, lancez une recherche et enregistrez un article.

Lequel choisir

Pour un site PHP, nous recommandons le moteur que votre hébergeur utilise déjà, maintenu sur une version prise en charge.

Si vous utilisez MySQL 8.0, votre prochaine étape est MySQL 8.4, et vous pouvez rester sur MySQL pour y arriver. Oracle a fait passer MySQL 8.0 au support de maintenance (Sustaining Support) le 21 avril 2026 et recommande aux utilisateurs de passer à la 8.4 ou à la 9.7. Selon le centre d'aide de DreamHost, les serveurs dédiés passent déjà à la 8.4, les serveurs partagés migrent selon le calendrier de DreamHost, et les clients MySQL VPS peuvent contacter le support pour en faire la demande.

Notre méthode de mesure

Nous avons effectué le test le 19 octobre 2026, sur une VM sous Colima, sur un Mac Apple M2 : arm64, 2 vCPU, 3 904 Mo de mémoire visible, pas de swap, Ubuntu 24.04.4 et Docker 29.5.2. Nous n'avons pas utilisé de serveur DreamHost. Nous avons utilisé les images officielles mysql:8.4.11 et mariadb:11.8.9, épinglées par empreinte (digest), sans rien modifier pour les tests avec la configuration d'origine. La mémoire au repos correspond à la médiane de 12 relevés docker stats pris à 5 secondes d'intervalle après 2 minutes de stabilisation, et elle n'avait pas bougé 10 minutes plus tard. Le benchmark était le test oltp_read_write de sysbench 1.0.20, avec 4 tables de 100 000 lignes, qui tiennent dans le buffer pool par défaut de 128 Mo de chaque moteur, 4 threads, 60 secondes de préchauffage, puis une seule exécution de 120 secondes par moteur et par configuration.

Nos serveurs VPS et dédiés utilisent des processeurs AMD EPYC : comparez donc les moteurs en proportion et ne vous attendez pas à y retrouver les mêmes valeurs absolues. Nous n'avons testé ni MySQL VPS, ni le MySQL partagé, ni notre image LAMP Stack. Chaque benchmark n'a été exécuté qu'une fois, sur des données synthétiques plus simples que le trafic d'un vrai site. L'exécution de MariaDB a également enregistré 683 erreurs que sysbench relance et comptabilise à part (environ 6 par seconde), contre aucune pour MySQL ; nous n'en avons pas cherché la cause. La vérification WordPress portait sur l'installation, le contenu généré et le chargement des pages, et chaque migration a utilisé l'outil d'export propre au moteur source.

FAQ sur MySQL et MariaDB