MySQL vs PostgreSQL : quelle base de données gagne ?

MySQL et PostgreSQL sont les deux candidats SGBDR entre lesquels la plupart des équipes choisissent réellement : matures, gratuits et capables de servir presque n'importe quel projet qu'on leur pointe. La question intéressante n'est pas qui gagne mais qui correspond à votre charge de travail, parce qu'ils optimisent pour des choses différentes : MySQL pour les lectures rapides à grande échelle, PostgreSQL pour la correction, la concurrence et l'extensibilité. Cette comparaison couvre l'architecture, la performance, la réplication, les licences et la migration, sur du bare metal à partir de 9,99 €/mois.

Qu'est-ce que MySQL ? Architecture de base et cas d'usage

MySQL est arrivé en 1995 et est devenu la base derrière la pile LAMP, WordPress et une grande partie du web. Oracle l'a acquis en 2010.

Son design définissant est le moteur de stockage enfichable. InnoDB est le défaut et fournit les transactions ACID, le verrouillage au niveau ligne et les clés étrangères ; d'autres moteurs existent pour des besoins spécialisés. Cette séparation entre la couche SQL et la couche de stockage est inhabituelle, et c'est pourquoi la performance de MySQL peut être si agressivement calibrée pour un seul pattern d'accès. Chaque moteur offre un jeu de garanties différent.

MySQL convient aux applications de production dominées par la lecture : sites de contenu, catalogues, stores de sessions, tout ce où l'ensemble de requêtes est connu et la structure stable. MySQL offre une réplication facile à mettre en place et bien comprise, et c'est pourquoi il s'est répandu via l'hébergement mutualisé.

MariaDB, le fork communautaire créé après l'acquisition par Oracle, reste drop-in compatible pour la plupart des charges de travail et mérite d'être connu quand la licence compte.

Qu'est-ce que PostgreSQL ? Fonctionnalités et communauté

PostgreSQL a grandi depuis la recherche académique à Berkeley et livre chaque septembre sans interruption depuis des décennies. PostgreSQL 18 a livré en septembre 2025 avec un sous-système d'I/O asynchrones qui hisse la performance en lecture, un skip scan sur les index B-tree multicolumn, et une fonction uuidv7().

Il n'y a aucune entreprise derrière. PostgreSQL appartient à sa communauté mondiale sous une licence permissive, ce qui est structurel plutôt que cosmétique : aucun vendeur ne peut changer les termes.

PostgreSQL offre une profondeur que MySQL ne tente pas, et chaque release en active davantage. Types de données personnalisés, opérateurs personnalisés, types d'index personnalisés, héritage de tables, window functions, common table expressions et un modèle d'extensions mature. PostGIS pour les données spatiales et pgvector pour les embeddings se branchent comme modules, pas comme forks, et c'est le pattern : la base grandit plutôt que d'être remplacée.

Différences architecturales clés entre MySQL et PostgreSQL

Typage strict. PostgreSQL rejette les données qui ne correspondent pas au type de colonne. MySQL a historiquement été plus accommodant, ce qui est commode jusqu'à ce qu'il tronque quelque chose en silence. Le mode strict comble la plus grande partie de cet écart sur les versions actuelles.

Modèle de processus. PostgreSQL fork un processus par connexion, si bien qu'un pooler de connexions tel que PgBouncer devient nécessaire plus tôt qu'on ne l'attend. MySQL utilise des threads et retient beaucoup de connexions idle plus à bas prix.

Benchmarks de performance : vitesse lecture/écriture et optimisation des requêtes

Les benchmarks publiés pour ces deux-là sont exécutés sur du matériel que vous n'avez pas, avec un mix de requêtes qui n'est pas le vôtre. Considérez la forme, pas les chiffres, et mesurez votre propre charge de travail avant de décider quoi que ce soit sur la seule vitesse.

Vitesse de lecture. Sur des lookups indexés plats avec un ratio de lecture élevé, MySQL est fréquemment l'option rapide. Le chemin de requête est plus court et l'optimiseur a moins à considérer. C'est la charge pour laquelle MySQL a été calibré, et la vitesse de lecture brute est là où elle se voit encore.

Débit d'écriture concurrent. PostgreSQL prend l'avance à mesure que la pression d'écriture concurrente monte. Son design MVCC signifie que les readers ne bloquent jamais les writers et que les writers ne bloquent jamais les readers, si bien que la vitesse d'écriture se dégrade plus gracieusement en production sous charge mixte.

Requêtes complexes. Le planner de PostgreSQL est le plus sophistiqué des deux. Sur des requêtes avec plusieurs joins, agrégats ou window functions, il trouvera généralement un meilleur plan, et l'écart de performance grandit avec la profondeur de la requête. L'optimiseur de MySQL s'est amélioré mais reste plus simple.

Indexation. MySQL offre l'indexation B-tree et hash plus la recherche full-text. PostgreSQL ajoute GIN, GiST, BRIN et les index partiels et d'expression, ce qui compte quand le dataset cesse d'être un simple arbre de lignes.

Le stockage domine les deux. La performance d'une base est liée aux I/O avant toute autre chose, et NVMe change plus que le choix du moteur. Notre guide sur les options de stockage pour bare metal couvre la différence.

Scalabilité et concurrence : scaling horizontal vs vertical

Les deux poussent bien verticalement, et une seule machine va plus loin que la plupart des équipes ne le supposent. La différence apparaît dans la façon de sortir à l'horizontale.

MySQL croît horizontalement par réplicas de lecture et, historiquement, par sharding au niveau applicatif. Group Replication et InnoDB Cluster donnent une haute disponibilité native. Sa gestion de connexions légère rend une grande flotte de lecture simple à opérer.

PostgreSQL sort à l'échelle par les réplicas de streaming et la voie logique. Parce que chaque connexion est un processus, un pooler fait partie de tout déploiement de production, et c'est une contrainte de scalabilité que vous devriez planifier. Des add-ons comme Citus apportent du sharding distribué quand un nœud ne suffit plus.

La règle pratique : si votre croissance est en volume de lecture, le modèle de réplicas de MySQL est l'option plus simple. Si votre croissance est en concurrence d'écriture ou en complexité de requêtes, PostgreSQL tient mieux sur une grande machine unique, ce qui est souvent de toute façon la réponse moins chère.

Types de données, support JSON et extensions avancées

Types de données. MySQL couvre l'ensemble standard. PostgreSQL ajoute les tableaux, les ranges, les types d'adresses réseau, les vecteurs de recherche full-text, et la capacité de définir les vôtres.

JSON. Les deux le stockent. MySQL le valide et l'écrit dans un format binaire avec un jeu de fonctions solide. PostgreSQL a json et jsonb, où JSONB est binaire, indexable avec GIN, et supporte les opérateurs de containment. Pour tout ce qui va au-delà de la gestion occasionnelle de documents, PostgreSQL est l'option la plus forte.

Modèle d'extensions. C'est là que l'écart est le plus large. PostGIS fait de PostgreSQL une plateforme spatiale sérieuse, pgvector en fait un vector store pour l'analytique et le retrieval, et TimescaleDB en fait une base de données time-series. Aucun de ces derniers n'exige un fork.

Réplication, haute disponibilité et reprise après sinistre

MySQL utilise une réplication basée sur le binlog, réellement facile à configurer. Asynchrone par défaut, semi-synchrone disponible, et Group Replication active le failover automatique. Le recovery point-in-time fonctionne à travers les binlogs.

PostgreSQL offre le streaming physique pour un standby identique à l'octet près et la réplication logique pour la copie sélective et inter-versions. Ce chemin logique est aussi ce qui rend les mises à niveau de version majeure moins disruptives. L'archivage continu active la récupération point-in-time, et des outils comme Patroni ou repmgr gèrent le failover automatique. Testez régulièrement une restauration pour vous assurer que l'archive est utilisable en production.

Aucun des deux n'est une sauvegarde. Un standby copie vos erreurs aussi fidèlement que vos données, si bien que l'histoire de disponibilité et l'histoire de récupération sont des problèmes séparés qui ont tous deux besoin d'une solution.

💡 Astuce Faites tourner la base sur sa propre machine dès qu'elle compte. Partager une boîte avec la couche applicative signifie qu'ils se disputent le même page cache. Notre page [serveur dédié base de données](https://www.kimsufi.com/fr/use-cases/uc-database-server/) couvre le dimensionnement.

Licences, coût total de possession et support vendeur

C'est la différence la plus nette entre eux, et elle n'est pas technique.

PostgreSQL utilise une licence permissive proche de BSD. Vous pouvez l'embarquer, le modifier et le redistribuer commercialement sans obligation, ce qui active des modèles de déploiement produit que MySQL rend pénibles. Aucune entreprise ne contrôle le projet.

MySQL est double-licencié : GPLv2 pour l'usage ouvert, et une licence payante d'Oracle quand les termes GPL ne conviennent pas à votre modèle de distribution. Pour une application côté serveur, ni l'un ni l'autre ne compte beaucoup. Pour un produit que vous livrez à des clients, cela compte énormément.

Support. Oracle vend MySQL Enterprise. PostgreSQL a un marché concurrentiel de vendeurs commerciaux dont EDB, Percona et Crunchy Data, si bien que le support est disponible sans être attaché à un quelconque propriétaire.

Coût en pratique. Les deux sont gratuits à faire tourner, donc cela ne dépend pas du prix. Le vrai coût est le temps d'ingénieur plus la machine, et la machine est le plus petit des deux nombres. Notre comparaison de l'hébergement dédié vs VPS couvre où cela se place.

Écosystème, outillage et intégration aux stacks de données modernes

MySQL a une portée énorme : chaque hébergeur mutualisé, chaque ORM, MySQL Workbench, phpMyAdmin, et chaque CMS que vous pouvez nommer. Si votre pile est WordPress ou une application PHP, l'intégration MySQL est le chemin par défaut et tout le suppose.

PostgreSQL est devenu le défaut dans le travail de données moderne. Les pipelines d'analytique, dbt, Airflow, Debezium change-data-capture et la plupart des offres cloud managées traitent PostgreSQL comme la cible primaire. Son support des foreign data wrappers lui permet d'interroger des systèmes externes en place.

Pour un pipeline de données qui nourrit l'analytique, l'écosystème PostgreSQL est maintenant clairement en avance. Pour une application web traditionnelle, la portée de MySQL reste inégalée.

Chemins de migration : passer de MySQL à PostgreSQL et inversement

La plupart du trafic de migration court dans un seul sens. Passer à PostgreSQL est courant ; revenir en arrière est rare.

Schéma. pgloader fait la plus grande partie de la conversion automatiquement, y compris le mapping des types. Relisez le résultat plutôt que de lui faire confiance.

Syntaxe. Les écarts de syntaxe mordent à des endroits précis : AUTO_INCREMENT devient GENERATED AS IDENTITY, les backticks deviennent des guillemets doubles, LIMIT x, y devient LIMIT y OFFSET x, et le GROUP BY permissif de MySQL échouera sous les règles plus strictes de PostgreSQL.

Procédures stockées. Toute procédure stockée ou trigger est une réécriture manuelle. Il n'y a pas de chemin automatique entre les deux langages procéduraux.

Code applicatif. Les ORMs absorbent l'essentiel. Le SQL brut et tout code qui repose sur les conversions implicites de types de MySQL exigeront de l'attention, et c'est habituellement là que se concentre l'effort de migration.

Faites tourner les deux en parallèle pendant la transition, comparez les résultats sur des requêtes réelles, et basculez par table plutôt qu'en une seule étape. Assurez que chaque stored function se comporte identiquement avant de basculer le trafic.

Choisir la bonne base de données pour des charges de travail précises

Contenu et commerce. WordPress, Magento et la plupart des plateformes CMS supposent MySQL. Le combattre n'en vaut pas la peine.

Analytique et reporting. PostgreSQL, pour le planner, les window functions et l'écosystème autour.

Géospatial. PostgreSQL avec PostGIS. Il n'y a pas de vraie concurrence ici.

Backends de jeu et services realtime. Les deux fonctionnent ; ce qui compte plus est la latence vers la machine et l'I/O cohérente. Voyez notre page sur les serveurs de jeu haute performance pour ce versant.

SaaS multi-tenant. PostgreSQL, pour l'isolation schema-per-tenant et la sécurité au niveau des lignes, qui laissent un seul déploiement servir beaucoup de clients en sécurité.

API à lectures dominantes avec un schéma plat. MySQL, pour le chemin de requête plus court et la mise en place de réplicas plus facile.

Si votre charge ne convient à aucun des deux moteurs, comme un stockage de documents ou un graphe, notre comparatif plus large des bases couvre MongoDB, MariaDB et Neo4j.

Verdict : MySQL ou PostgreSQL pour votre projet 2026 ?

Choisissez PostgreSQL si vous partez de zéro, si la correction des données compte, si vos requêtes sont complexes, si vous avez besoin des documents comme type de première classe, ou si les licences doivent rester permissives. Pour la plupart des nouveaux projets ce choix est le bon défaut.

Choisissez MySQL si votre pile le suppose déjà, si votre charge de travail est dominée par la lecture avec un schéma simple, ou si votre équipe le connaît bien. La réponse dépend plus de votre situation que de l'un ou l'autre moteur, et une équipe qui sait bien gérer une base bat une base marginalement meilleure que personne ne connaît. Sur un serveur dédié, notre guide de mise en place MySQL vous mène de l'installation à une instance durcie et réglée.

Dans tous les cas, faites-la tourner sur du matériel que vous contrôlez. La performance ici est dominée par les I/O et la mémoire, et une instance managée facture un multiple pour les mêmes ressources. Nos pages sur les cas d'usage bare metal et l'hébergement dédié couvrent les options.

Foire aux questions