WordPress et PostgreSQL : faut-il quitter MySQL en 2026 ?

PostgreSQL est une base de données relationnelle reconnue pour sa robustesse, ses fonctions avancées et son adoption dans de nombreux projets applicatifs. Son nom revient donc régulièrement dans les discussions techniques autour de WordPress, en particulier chez les équipes qui utilisent déjà PostgreSQL pour leurs applications métier, leurs outils d’analyse ou leurs API.

Pour autant, la question « faut-il quitter MySQL pour PostgreSQL avec WordPress ? » appelle une réponse nuancée. WordPress est historiquement conçu autour de MySQL, avec une compatibilité officielle qui couvre également MariaDB. PostgreSQL n’est pas une option proposée par l’installateur standard, ni un choix que la plupart des hébergeurs WordPress managés mettent à disposition pour leurs offres classiques.

Avant de rechercher un hébergement PostgreSQL, il est donc essentiel de distinguer les bénéfices potentiels de la base de données, la compatibilité réelle du CMS et les conséquences concrètes sur la maintenance d’un site. Pour un blog, un site vitrine, une boutique WooCommerce ou un média WordPress classique, changer de moteur de base de données n’est généralement pas la première optimisation à envisager.

Pourquoi PostgreSQL revient dans les discussions autour de WordPress

PostgreSQL est un système de gestion de base de données relationnelle open source. Il est notamment apprécié dans les environnements de développement pour la richesse de son langage SQL, ses mécanismes de contraintes, ses types de données avancés, sa gestion transactionnelle et ses possibilités d’extension.

Dans un contexte applicatif, PostgreSQL peut par exemple être retenu pour :

des applications qui manipulent beaucoup de données structurées ou semi-structurées ;
des projets ayant besoin de requêtes analytiques complexes ;
des architectures utilisant des données géographiques via l’extension PostGIS ;
des équipes qui veulent standardiser leur parc technique autour d’un même moteur de base de données ;
des infrastructures cloud où PostgreSQL est déjà exploité sous forme de service managé.

Les services tels qu’Amazon RDS for PostgreSQL, Cloud SQL for PostgreSQL ou DigitalOcean Managed PostgreSQL facilitent d’ailleurs l’exploitation d’instances PostgreSQL administrées dans des architectures sur mesure.

Cette disponibilité alimente logiquement l’idée d’utiliser le même moteur pour WordPress. Pourtant, l’existence d’un PostgreSQL managé ne suffit pas à rendre WordPress compatible avec PostgreSQL. Il faut d’abord regarder comment le CMS accède à sa base de données.

Le débat est aussi relancé par la montée des architectures découplées. Dans un projet headless, WordPress peut servir de back-office éditorial et exposer son contenu via l’API REST ou GraphQL, tandis que le front-end est développé avec Next.js, Nuxt ou un autre framework. Les équipes ont alors davantage tendance à comparer l’ensemble des briques techniques, y compris le moteur de base de données. Mais même dans cette configuration, le cœur de WordPress reste dépendant de son modèle de données et de ses conventions SQL historiques.

WordPress repose officiellement sur MySQL et MariaDB

WordPress utilise une couche d’accès aux données centrée sur la classe wpdb. Elle s’appuie sur les fonctions et comportements des bases MySQL compatibles. La documentation des prérequis de WordPress indique la prise en charge de MySQL et de MariaDB ; PostgreSQL ne fait pas partie des moteurs officiellement supportés pour une installation WordPress standard.

Dans la pratique, cela signifie qu’un hébergement compatible WordPress propose presque toujours :

MySQL ;
MariaDB ;
un accès à phpMyAdmin ou à un outil équivalent ;
la création de bases et d’utilisateurs depuis un panneau d’administration ;
des procédures de sauvegarde et de restauration conçues pour ces moteurs.

Ce choix n’est pas anodin. Les tables de WordPress, comme wp_posts, wp_postmeta, wp_options ou wp_users, ont été pensées pour MySQL. De nombreux appels SQL présents dans le cœur, les extensions et les thèmes supposent des syntaxes, des fonctions ou des particularités de ce moteur.

Par exemple, des extensions peuvent utiliser des éléments spécifiques à MySQL tels que :

la syntaxe INSERT ... ON DUPLICATE KEY UPDATE ;
des fonctions de date et de chaîne propres à MySQL ;
des instructions SHOW pour inspecter les tables ou les index ;
des options de création de table comme le moteur de stockage ou le jeu de caractères ;
des requêtes SQL construites directement, sans couche d’abstraction adaptée à plusieurs moteurs.

Un adaptateur peut parfois traduire une partie de ces différences. Toutefois, il ne peut pas garantir automatiquement le fonctionnement de l’ensemble de l’écosystème WordPress. C’est un point fondamental : la compatibilité ne se résume pas à réussir l’installation initiale du CMS.

Pour la plupart des propriétaires de sites, rester sur MySQL ou MariaDB est donc moins un manque d’ambition technique qu’un choix de compatibilité, de simplicité opérationnelle et de facilité de support.

MySQL, MariaDB et PostgreSQL : les différences utiles pour un site WordPress

Comparer les moteurs uniquement à partir de leur réputation est rarement utile. Le bon choix dépend de l’application utilisée, de la charge réelle, des compétences disponibles et des outils de maintenance. Dans le cas de WordPress, la compatibilité applicative doit passer avant les préférences générales pour un moteur SQL.

MySQL : la référence historique de WordPress

MySQL est le moteur historiquement associé à WordPress. Il est disponible chez quasiment tous les hébergeurs mutualisés, VPS et clouds. Les outils de migration, les scripts d’installation, les panneaux d’hébergement et les services de sauvegarde sont très largement construits autour de cet environnement.

Pour un administrateur WordPress, les avantages pratiques sont clairs : documentation abondante, grand nombre de prestataires, compatibilité avec les extensions connues et procédures de dépannage bien établies. Lorsqu’un site doit être déplacé, un export SQL, une sauvegarde réalisée par l’hébergeur ou un outil comme WP-CLI sont généralement plus simples à exploiter dans un environnement MySQL ou MariaDB standard.

MariaDB : une alternative courante, mais pas interchangeable sur tous les détails

MariaDB est un moteur issu d’un fork de MySQL. De nombreux hébergeurs l’emploient pour leurs offres web. Pour WordPress, MariaDB est un choix habituel et officiellement pris en charge par les prérequis du CMS.

Il ne faut toutefois pas considérer MySQL et MariaDB comme strictement identiques dans toutes les versions et tous les usages. Les deux projets ont évolué séparément. Certaines différences peuvent concerner l’optimiseur de requêtes, les fonctionnalités disponibles ou l’administration. Pour un site WordPress courant, ces écarts sont le plus souvent transparents. En revanche, une extension qui exécute des requêtes avancées mérite toujours des tests sur l’environnement cible.

PostgreSQL : des atouts réels, mais hors du chemin standard de WordPress

PostgreSQL est un moteur mature et puissant. Il peut être particulièrement pertinent lorsque la base de données est au cœur d’une application spécifique : règles métier complexes, géodonnées, traitements analytiques, intégrations sur mesure ou besoins transactionnels très encadrés.

Ces qualités ne se traduisent pas automatiquement par un gain pour WordPress. Une installation WordPress typique repose fortement sur les métadonnées. Les tables comme wp_postmeta et wp_usermeta peuvent contenir un volume élevé de lignes selon les extensions installées. La performance dépend alors de nombreux paramètres : qualité des requêtes, index, cache objet, cache de pages, thème, extensions, CPU, mémoire, stockage et trafic.

Changer de moteur de base de données ne corrige pas une extension mal optimisée, un trop grand nombre de requêtes sur chaque page ou l’absence de cache adapté.

Avant d’envisager PostgreSQL, il est généralement plus rationnel d’appliquer les optimisations WordPress éprouvées : activer un cache de pages, utiliser un cache objet lorsque le contexte le justifie, examiner les extensions lourdes et contrôler les requêtes lentes. Notre guide pour optimiser WordPress sur votre hébergement détaille ces leviers plus directement exploitables.

Peut-on techniquement faire fonctionner WordPress avec PostgreSQL ?

Des projets communautaires ont tenté, au fil du temps, d’adapter WordPress à PostgreSQL au moyen de couches de compatibilité. Le principe consiste à intercepter ou traduire des requêtes prévues pour MySQL afin qu’elles soient exécutables par PostgreSQL.

Cette approche peut être utile dans un contexte de laboratoire, de développement ou de preuve de concept. Elle ne transforme pas PostgreSQL en moteur officiellement supporté par WordPress. Surtout, elle ajoute une couche supplémentaire entre WordPress et la base de données, avec des risques lors des mises à jour du cœur, des extensions ou des thèmes.

Un projet qui s’appuie sur cette voie doit prévoir :

un environnement de préproduction aussi proche que possible de la production ;
des tests après chaque mise à jour de WordPress ;
des tests fonctionnels pour les extensions stratégiques ;
une procédure de restauration réellement validée ;
une personne capable de diagnostiquer des problèmes SQL et PHP ;
un plan de sortie vers MySQL ou MariaDB si l’adaptateur n’est plus maintenu.

Le coût principal n’est donc pas forcément l’hébergement PostgreSQL lui-même. Il se situe dans le temps de maintenance, le risque de régression et la difficulté à obtenir du support. Un hébergeur WordPress pourra légitimement refuser de prendre en charge un dysfonctionnement lié à une couche PostgreSQL non standard, même s’il héberge par ailleurs votre serveur.

Dans ce scénario, WordPress devient une composante personnalisée d’une infrastructure sur mesure. C’est envisageable pour une équipe technique qui assume cette responsabilité. Ce n’est pas le modèle adapté à une petite entreprise qui veut administrer son site depuis un panneau simple ou confier les incidents à un support mutualisé.

Compatibilité des thèmes, extensions et sauvegardes : les points de vigilance

La difficulté d’un passage à PostgreSQL n’est pas seulement liée au cœur de WordPress. Elle concerne surtout les nombreuses briques qui gravitent autour du CMS. Plus un site est ancien, riche en extensions ou connecté à des services tiers, plus le niveau de risque augmente.

Les extensions WordPress

Une extension peut fonctionner avec PostgreSQL sur certaines pages, puis échouer sur une fonctionnalité moins utilisée : import de données, génération de rapports, tâche planifiée, recherche interne ou commande WooCommerce. Les extensions e-commerce, de réservation, de formulaire, de sécurité, de statistiques ou de cache sont particulièrement sensibles, car elles créent souvent leurs propres tables et exécutent des requêtes spécifiques.

WooCommerce, par exemple, s’appuie sur WordPress et sur une base de données compatible MySQL/MariaDB dans son cadre d’utilisation classique. Introduire PostgreSQL au travers d’un adaptateur oblige à tester les commandes, le stock, les remboursements, les webhooks, les tâches planifiées et les extensions de paiement réellement utilisées. Il ne faut jamais déduire la compatibilité d’un test limité à l’affichage du catalogue.

Les thèmes et développements sur mesure

Un thème bien construit utilise normalement les API WordPress, telles que WP_Query, les fonctions de métadonnées et les API de taxonomies. Mais les développements personnalisés utilisent parfois directement l’objet $wpdb, voire intègrent des requêtes SQL écrites pour MySQL.

Avant toute migration, un audit de code est nécessaire. Il faut notamment rechercher les requêtes SQL directes, les appels à des fonctions MySQL spécifiques, les créations de tables personnalisées et les opérations d’import/export. Sans cet inventaire, un basculement en production revient à tester le site sur les visiteurs.

Les sauvegardes, migrations et outils d’administration

Les outils WordPress les plus répandus sont généralement conçus autour du couple WordPress + MySQL/MariaDB. C’est le cas des sauvegardes proposées par de nombreux hébergeurs, des exports via phpMyAdmin, ou de nombreuses extensions de migration.

Avec PostgreSQL, les procédures changent. L’outil de ligne de commande pg_dump est la solution habituelle pour exporter une base PostgreSQL, tandis que pg_restore peut restaurer des sauvegardes dans certains formats. Ces outils sont fiables dans un cadre PostgreSQL, mais ils ne résolvent pas le problème de compatibilité de WordPress ni celui de la traduction des données et des requêtes.

Une stratégie de sauvegarde sérieuse doit inclure à la fois les fichiers WordPress, la base de données, les fichiers médias et les éventuelles données externes. Elle doit aussi être testée. Une sauvegarde qui existe mais qui n’a jamais été restaurée ne constitue pas une garantie opérationnelle.

Les performances : pourquoi PostgreSQL n’est pas un raccourci

Il est tentant de croire qu’un moteur réputé plus avancé rendra immédiatement un WordPress plus rapide. Cette logique ne tient pas compte du fonctionnement réel d’un site web.

Sur un WordPress classique, les gains les plus visibles proviennent souvent de mesures comme :

un hébergement avec des ressources CPU et mémoire adaptées ;
un stockage performant et une configuration PHP correcte ;
un cache de pages côté serveur ou via une extension ;
un CDN pour distribuer les ressources statiques au plus près des visiteurs ;
la réduction des extensions inutiles ;
l’optimisation des images et des scripts chargés par le thème ;
l’analyse des requêtes lentes et des tâches planifiées.

Un cache de pages peut éviter l’exécution de PHP et de nombreuses requêtes SQL pour les visiteurs non connectés. Dans ce cas, le moteur de base de données n’est pas sollicité de la même manière qu’en back-office ou sur un site e-commerce dynamique.

Pour WooCommerce, les espaces membres, les sites multilingues lourds ou les plateformes à fort trafic connecté, la base de données mérite davantage d’attention. Mais la méthode reste la même : mesurer avant de modifier. Des outils comme Query Monitor peuvent aider à identifier les requêtes, hooks et composants coûteux dans un environnement de développement. Côté infrastructure, les journaux de requêtes lentes et les outils de supervision de l’hébergeur apportent des informations plus utiles qu’un changement de moteur décidé a priori.

Les enjeux de performance ne doivent pas masquer ceux de disponibilité. Une base MySQL ou MariaDB bien administrée, sauvegardée et monitorée sera préférable à une base PostgreSQL théoriquement plus adaptée mais difficile à maintenir dans une stack WordPress non standard.

Quel hébergement choisir selon votre projet et votre base de données ?

Le choix de l’hébergement doit partir du projet WordPress et non de la seule technologie de base de données. Voici des repères concrets selon les situations les plus fréquentes.

Blog, site vitrine ou portfolio

Pour un site de présentation, un blog éditorial ou un portfolio, MySQL ou MariaDB est le choix logique. Un hébergement mutualisé de qualité ou un hébergement WordPress managé couvre généralement les besoins, à condition de vérifier les ressources proposées, les sauvegardes, le support PHP, le certificat TLS et les outils de mise en cache.

Dans ce cas, PostgreSQL ne procure pas un avantage pratique suffisant pour justifier les contraintes de compatibilité. Consultez aussi notre dossier hébergement WordPress managé ou mutualisé pour choisir le niveau d’accompagnement approprié.

Boutique WooCommerce ou site avec espace membre

Une boutique, une plateforme de formation ou un site à comptes utilisateurs actifs nécessite un hébergement plus attentif aux ressources et à la base de données. MySQL ou MariaDB demeure là encore la voie normale, avec un environnement qui accepte les tâches cron, les sauvegardes fréquentes, le cache objet si nécessaire et une montée en puissance possible.

Privilégiez un prestataire qui connaît WooCommerce et qui explique clairement ses limites de ressources. Vérifiez aussi les modalités de restauration, la localisation des données si elle compte pour votre organisation et l’accès aux journaux techniques.

Projet WordPress sur mesure intégré à une infrastructure existante

PostgreSQL peut être envisagé lorsqu’une équipe de développement possède déjà une expertise solide sur ce moteur et qu’elle assume une intégration non standard. Cela concerne davantage une organisation ayant un VPS, des conteneurs ou une infrastructure cloud pilotée par ses propres équipes qu’un client d’offre WordPress clé en main.

Dans ce contexte, il faut séparer deux sujets :

la base utilisée par WordPress lui-même, qui devrait rester MySQL ou MariaDB pour préserver la compatibilité ;
une base PostgreSQL dédiée à une application métier, un service externe ou une API connectée à WordPress.

Cette architecture hybride est souvent plus réaliste. WordPress conserve sa base supportée, tandis que PostgreSQL héberge les données pour lesquelles il a été choisi. Les échanges peuvent passer par une API, une extension développée sur mesure ou un middleware. Cela demande de l’architecture, mais évite de forcer WordPress à utiliser un moteur qu’il ne supporte pas nativement.

VPS ou cloud administré par une équipe technique

Un VPS donne davantage de liberté : installation de PostgreSQL, réglages système, supervision et déploiement personnalisé. Cette liberté implique aussi la responsabilité des mises à jour de sécurité, de la configuration du serveur web, de PHP, de la base, des sauvegardes et de la surveillance.

Le NVMe, les ressources allouées ou les dernières versions de protocoles réseau ne compensent pas une architecture mal maîtrisée. Si vous optez pour cette voie, notre article sur le VPS NVMe pour WordPress permet de replacer le stockage dans une évaluation plus globale de l’infrastructure.

Comment vérifier ce que votre hébergeur prend réellement en charge

Un hébergeur peut proposer PostgreSQL dans son catalogue cloud ou VPS sans proposer WordPress sur PostgreSQL. Les deux affirmations ne sont pas équivalentes. Avant de souscrire, posez des questions précises au support commercial ou technique.

WordPress est-il officiellement pris en charge avec PostgreSQL sur cette offre ?
Le support intervient-il en cas de problème lié à l’adaptateur PostgreSQL utilisé ?
Les sauvegardes automatiques incluent-elles la base PostgreSQL et les fichiers WordPress ?
Quelle procédure de restauration est proposée et pouvez-vous la tester ?
Disposez-vous d’un environnement de staging ou devrez-vous le créer vous-même ?
Quels outils d’administration de base de données sont disponibles ?
Le serveur permet-il l’accès SSH et l’exécution des outils nécessaires, notamment pg_dump ?
Qui sera responsable des mises à jour de WordPress, PHP, PostgreSQL et de la couche de compatibilité ?

Une réponse vague du type « PostgreSQL est disponible » ne doit pas être interprétée comme une validation de compatibilité WordPress. Demandez une confirmation écrite et, pour un projet important, réalisez un prototype sur un environnement isolé avant toute migration.

Cette vérification s’inscrit dans une démarche plus large. Notre guide sur les éléments à vérifier avant de choisir un hébergement WordPress peut vous aider à comparer le support, les sauvegardes, les performances et la sécurité au-delà des arguments commerciaux.

Conclusion : faut-il quitter MySQL pour PostgreSQL avec WordPress ?

En 2026, PostgreSQL reste une technologie pertinente pour de nombreux projets web, mais il ne constitue pas un remplacement direct de MySQL ou MariaDB pour WordPress. Le CMS, ses extensions, ses thèmes et l’écosystème des hébergeurs sont majoritairement conçus pour les moteurs officiellement supportés.

Pour un site WordPress standard, rester sur MySQL ou MariaDB est le choix le plus fiable, le plus simple à maintenir et le plus facile à faire accompagner. Les performances doivent d’abord être travaillées par le cache, la qualité de l’hébergement, l’optimisation des extensions et l’analyse des requêtes réelles.

PostgreSQL peut avoir sa place dans une architecture sur mesure, notamment comme base dédiée à un service métier relié à WordPress. Si vous envisagez malgré tout de l’utiliser pour le cœur du CMS, traitez ce choix comme un projet d’ingénierie : prototype, tests complets, sauvegardes validées et compétences internes sont indispensables. Avant de changer de base de données, comparez surtout les offres d’hébergement selon les besoins concrets de votre site et le niveau de support dont vous avez besoin.