PostgreSQL vs MySQL en 2026 : quelle base de données pour votre application web ou votre SaaS ?
C'est la première décision d'infrastructure de la plupart des projets, et celle dont on débat le plus longtemps. Un comparatif honnête, sans tribalisme, de PostgreSQL et MySQL pour les applications web et les SaaS en 2026 — fonctionnalités, performance, écosystème, et les questions qui devraient réellement décider.
Peu de questions génèrent autant de réponses confiantes et opposées que « PostgreSQL ou MySQL ? ». Demandez sur un forum et Postgres est le seul choix sérieux ; demandez sur un autre et MySQL fait tourner la moitié d'Internet, alors où est le débat ? Ayant construit et réglé des systèmes de production sur les deux — c'est au cœur de mon travail d'architecture de bases de données — ma réponse honnête est qu'ils sont tous deux excellents en 2026, qu'ils diffèrent sur des points précis et connaissables, et que le bon choix relève surtout de votre application, de votre équipe et de votre écosystème. Laissez-moi vous montrer la décision telle que je la présente aux clients.
La version courte, pour les impatients
Par défaut, PostgreSQL pour une nouvelle application web ou un nouveau SaaS, sauf si un facteur précis ci-dessous pointe dans l'autre sens. Choisissez MySQL quand votre plateforme ou votre équipe est déjà construite autour (écosystèmes d'hébergement Laravel/PHP, WordPress, expertise MySQL existante) — une organisation qui parle couramment MySQL le fera mieux tourner qu'un Postgres à la mode qu'elle ne comprend pas. Dans les deux cas, la conception du schéma et la qualité des requêtes compteront dix fois plus que le logo sur la base. Le reste de cet article est le raisonnement, parce que « par défaut » n'est pas un argument.
Où PostgreSQL prend réellement l'avantage
Types de données et puissance de requête. JSONB avec une vraie indexation, tableaux, intervalles, recherche plein texte intégrée, fonctions fenêtres, CTE, jointures latérales — PostgreSQL vous permet d'exprimer en une requête correcte des choses que MySQL rend pénibles ou impossibles. Pour les produits SaaS, dont les besoins de rapports et de filtrage deviennent créatifs avec le temps, c'est l'avantage que je ressens le plus souvent sur des projets réels.
La sophistication de l'indexation. Index partiels (n'indexer que les commandes en attente), index sur expressions, index composites avec colonnes incluses, GIN/GiST/BRIN pour le JSON, les tableaux, le géospatial et les séries temporelles. Quand un produit commence à forcer, Postgres donne à l'optimiseur — et à moi — davantage de leviers. Mon guide des index est, de façon révélatrice, un article PostgreSQL.
Normes et correction. Vérification de types plus stricte, DDL transactionnel (la plupart des changements de schéma peuvent être annulés), et une philosophie générale de « refuser de faire silencieusement la mauvaise chose » — MySQL a comblé une grande partie de cet écart avec ses réglages modernes, mais les défauts de Postgres sont les stricts depuis plus longtemps.
Extensions et élan de l'écosystème. PostGIS pour le géospatial (toujours la référence), pgvector pour les embeddings d'IA, Timescale pour les séries temporelles, et toute la vague moderne des bases managées (Supabase, Neon) est fondée sur Postgres. L'énergie des nouvelles infrastructures SaaS en 2026 est disproportionnellement une énergie PostgreSQL.
Où MySQL tient réellement son rang
Le monde PHP/Laravel/WordPress. La plus grande base installée de l'hébergement web. Hébergement mutualisé, cPanel, les outils que votre agence connaît déjà — si votre monde est PHP, MySQL est l'eau dans laquelle il nage, avec un excellent support Laravel/Eloquent. Combattre son écosystème pour suivre un benchmark est rarement sage.
Familiarité opérationnelle et réplication simple. L'histoire primaire/réplica de MySQL est historiquement la plus simple et la plus éprouvée, et il y a tout simplement plus d'ingénieurs et de panneaux d'hébergement qui la connaissent. Une base que votre équipe sait opérer en confiance à 3 heures du matin bat une base théoriquement supérieure qu'elle ne maîtrise pas.
Simplicité orientée lecture. Pour des charges simples et dominées par la lecture (sites de contenu, catalogues), MySQL est rapide, tolérant et bon marché à exploiter — ses années à faire tourner d'énormes propriétés n'étaient pas un accident.
Le MySQL moderne (8.x) mérite aussi qu'on soit juste : il a désormais les CTE, les fonctions fenêtres et de bien meilleurs réglages par défaut que sa réputation ne le suggère. L'écart est réel, mais plus étroit que le folklore.
Les facteurs qui devraient réellement décider
La maîtrise de votre équipe. Le facteur le plus fort. Sauvegardes, réglages, réponse aux incidents — un moteur compris bat un moteur admiré.
Votre plateforme. WordPress/WooCommerce ou une pile centrée PHP penche vers MySQL ; une pile moderne Next.js/Node/SaaS avec un outillage type Supabase penche vers Postgres.
La forme de vos données. Interrogation JSON lourde, géospatial, rapports de type analytique, fonctions d'IA (embeddings) → PostgreSQL, de façon décisive.
Votre histoire de croissance. Les deux vont bien au-delà des besoins de la plupart des produits quand ils sont correctement indexés et réglés. Aucun ne sauve un mauvais schéma.
L'hébergement managé que vous utiliserez réellement. Si vous voulez le Postgres serverless type Supabase/Neon ou, inversement, le MySQL managé que votre hébergeur inclut gratuitement, laissez la plateforme tirer la décision.
L'erreur que je vois réellement sur le terrain
Ce n'est pas de choisir le « mauvais » moteur — c'est de s'angoisser sur le moteur tout en livrant un schéma sans index, des colonnes texte pour les dates, et un ORM qui génère des requêtes N+1. J'ai sauvé des applications MySQL lentes et des applications PostgreSQL lentes avec les mêmes remèdes : modélisation saine, bons index, mesure honnête des requêtes. Si vous débutez, prenez PostgreSQL, dépensez votre budget d'inquiétude sur le schéma, et passez à la construction du produit. Si vous êtes déjà sur MySQL et que ça fonctionne, restez, réglez-le correctement, et ignorez les forums.
Choisir ou sauver une base de données est littéralement mon service d'architecture et d'optimisation de bases de données — y compris les migrations MySQL vers PostgreSQL quand le dossier du déménagement est réel. Si vous êtes à ce carrefour et voulez une recommandation fondée sur votre pile plutôt que sur les opinions d'Internet, dites-moi ce que vous construisez.