Pendant 20 ans, le débat PostgreSQL vs MySQL a divisé les développeurs. En 2026, ce débat est presque clos : PostgreSQL est devenu le choix par défaut pour 90 % des nouveaux projets, même chez d'anciens fans de MySQL. Voici pourquoi cette bascule a eu lieu et dans quels rares cas MySQL reste pertinent.
Pourquoi PostgreSQL a gagné
Trois raisons principales expliquent le basculement. Premièrement, PostgreSQL fait tout ce que MySQL fait, et plus : transactions ACID, réplication, partitionnement, performances. Deuxièmement, ses fonctionnalités avancées (JSON natif, full-text, PostGIS, extensions) sont devenues indispensables. Troisièmement, son écosystème open source est plus actif et neutre que MySQL (racheté par Oracle en 2010).
Le killer feature : JSONB
PostgreSQL stocke et indexe le JSON en natif via le type `JSONB`. Vous pouvez requêter, filtrer, indexer des champs JSON avec des performances proches du SQL standard. C'est le seul moyen pratique de mélanger structure relationnelle et données semi-structurées sans dupliquer les schémas. MySQL a ajouté JSON en 5.7 mais l'implémentation reste inférieure.
Les extensions qui changent tout
PostgreSQL est extensible : vous installez des extensions qui ajoutent des fonctionnalités natives. Quelques-unes essentielles en 2026 : PostGIS (géolocalisation), pg_trgm (recherche fuzzy), pgvector (recherche sémantique pour IA), TimescaleDB (séries temporelles), citus (sharding distribué). MySQL n'a pas d'équivalent.
Performances : qui gagne ?
Sur les requêtes SELECT simples avec peu de jointures, MySQL est souvent 10-15 % plus rapide. Sur les requêtes complexes avec multiples jointures, agrégations et fenêtres, PostgreSQL prend l'avantage de 20-40 %. Pour un site moderne avec ORM et requêtes complexes, PostgreSQL est plus performant en pratique.
Compatibilité ORM et frameworks
Tous les ORMs majeurs (Prisma, TypeORM, Sequelize, SQLAlchemy, Doctrine, Eloquent) supportent les deux, mais avec une nette préférence PostgreSQL. Les nouvelles fonctionnalités sont souvent disponibles d'abord sur PostgreSQL (par exemple Prisma JSON queries, TimescaleDB hypertables).
Quand MySQL reste pertinent
Trois cas. Premièrement, si vous avez déjà un écosystème MySQL massif (WordPress, PrestaShop, Magento dépendent fortement de MySQL/MariaDB). Deuxièmement, pour les workloads en lecture massive avec read replicas (MySQL a une longue avance sur ce point). Troisièmement, si votre hébergeur ne propose que MySQL (rare en 2026).
MariaDB : la troisième voie
MariaDB est un fork de MySQL maintenu par les créateurs originaux de MySQL après le rachat par Oracle. Il est 100 % compatible MySQL mais évolue plus rapidement. C'est devenu le choix de Wikipedia, Google, Mozilla. Si vous voulez du MySQL en 2026, prenez plutôt MariaDB.
Migration depuis MySQL : combien de temps ?
Pour une base simple (e-commerce moyen, blog), 1-2 jours de migration et tests. Pour une base complexe avec procédures stockées et triggers, 1-2 semaines. Outils utiles : pgloader (import direct), pg_dump/pg_restore (sauvegarde), AWS DMS (migration cloud). Le code applicatif demande peu de modifications grâce aux ORMs.
Hébergement managed
PostgreSQL est disponible chez tous les cloud providers en mode managed : Amazon RDS, Google Cloud SQL, Azure Database, Supabase, Neon, Railway, Crunchy Bridge. Les prix sont comparables à MySQL, parfois moins chers. Aucune raison technique ou économique de rester sur MySQL en 2026.
Conclusion
Pour un nouveau projet en 2026, choisissez PostgreSQL sans hésiter. C'est plus rapide, plus puissant, plus extensible, et l'écosystème est plus dynamique. MySQL reste pertinent pour des projets legacy ou des stacks WordPress/Magento, mais ce n'est plus un choix par défaut. Le débat est tranché par la pratique.