Ouvrir un panel d’hébergement et lire « MariaDB 10.6 » plutôt que « MySQL 8.0 » laisse souvent perplexe un développeur WordPress qui n’a jamais eu à s’en soucier. Historiquement, WordPress s’est construit avec MySQL, et le nom est resté dans l’imaginaire collectif comme synonyme de « la base de données de WordPress ». Pourtant, la majorité des hébergeurs mutualisés et de nombreux VPS proposent désormais MariaDB par défaut.
La bonne nouvelle est que WordPress fonctionne avec les deux sans configuration particulière : la couche wpdb qui gère les requêtes en base ne fait pas de distinction. Mais pour un développeur qui doit optimiser des requêtes, dimensionner un serveur ou migrer une base volumineuse, comprendre ce qui distingue réellement les deux moteurs évite de mauvaises surprises.
Une histoire commune, une trajectoire divergente
MariaDB est un fork de MySQL créé en 2009 par les fondateurs historiques du projet, en réaction directe au rachat de Sun Microsystems (qui possédait alors MySQL) par Oracle. L’objectif affiché était de garantir la pérennité d’un moteur de base de données réellement open source, indépendant des décisions commerciales d’un éditeur unique. Pendant plusieurs années, MariaDB est resté un miroir quasiment parfait de MySQL, avec les mêmes numéros de version et une compatibilité totale.
Depuis, les deux projets ont pris des chemins distincts. MariaDB a introduit ses propres moteurs de stockage (comme Aria ou ColumnStore) et un système de numérotation de version indépendant, tandis que MySQL a évolué sous la direction d’Oracle avec ses propres priorités, notamment autour des fonctionnalités JSON et des transactions.
Ce qui change concrètement pour un site WordPress
Pour l’immense majorité des sites, la différence reste invisible au quotidien. WordPress utilise principalement le moteur InnoDB (ou son équivalent) pour ses tables, disponible et globalement équivalent sur les deux systèmes. Les fonctions SQL de base utilisées par les requêtes de WordPress sont communes aux deux moteurs.
Les différences apparaissent surtout sur des cas avancés : certaines extensions qui exploitent des fonctions JSON spécifiques à MySQL 8 peuvent se comporter différemment sous MariaDB, dont l’implémentation JSON a suivi un calendrier distinct. De même, l’optimiseur de requêtes de MariaDB gère parfois différemment certaines jointures complexes, ce qui peut se traduire par des plans d’exécution différents sur une même requête lente à optimiser.
Migrer de l’un vers l’autre
La migration se fait avec les mêmes outils dans les deux sens, ce qui rassure sur la portabilité réelle des données :
mysqldump --single-transaction -u utilisateur -p nom_base > export.sql
Ce fichier d’export SQL s’importe ensuite tel quel sur l’autre moteur, sans transformation particulière dans la quasi-totalité des cas rencontrés sur des bases WordPress standards :
mysql -u utilisateur -p nom_base < export.sql
Les rares cas de blocage concernent des bases utilisant des fonctionnalités très récentes et spécifiques à une version précise de l'un des deux moteurs, ce qui reste marginal sur un site WordPress classique sans extension exotique manipulant directement du SQL avancé.
Quelques points de vigilance à la migration
- Vérifier la version exacte du moteur cible avant de migrer, certaines fonctions de tri de chaînes de caractères (collation) ont des noms ou des comportements légèrement différents.
- Recréer les utilisateurs et leurs droits, l'export
mysqldumpstandard ne les inclut pas. - Tester les extensions qui interrogent directement la base via
$wpdbavec du SQL personnalisé, plutôt que via l'API WordPress classique.
Le choix entre MariaDB et MySQL relève rarement d'un critère technique décisif pour un site WordPress standard. C'est davantage une question de disponibilité chez l'hébergeur et d'habitude de l'équipe qui administre le serveur.
En résumé
MariaDB et MySQL restent, pour la grande majorité des usages WordPress, deux choix équivalents et largement interchangeables. La vigilance est surtout de mise pour des extensions avancées manipulant du SQL personnalisé, ou pour des migrations entre versions très éloignées dans le temps. Dans le doute, tester la migration sur une copie de la base avant toute bascule en production reste la seule vérification qui vaille.
