MySQL vs PostgreSQL en 2026 : un cadre de décision pratique

J'ai été des deux côtés de ce débat, et je l'ai vu mal tourner dans les deux sens.

Le camp PostgreSQL te dira que ce n'est même pas une question — MySQL est une base de données héritée, Postgres est le bon choix, passe à autre chose. Le camp MySQL te dira que Postgres est une base de données lente et sur-ingénierée, très bien pour les amateurs et catastrophique sous charge, et que MySQL fait tourner la moitié d'internet depuis vingt ans, alors quel est le débat ?

Ces deux positions sont paresseuses, et elles viennent du même endroit : des gens qui ont utilisé en profondeur l'une de ces bases et à peine l'autre. Si tu as passé cinq ans dans Postgres, les bizarreries de MySQL ressemblent à des défauts de conception. Si tu as passé cinq ans dans MySQL, la cérémonie de Postgres ressemble à de la surcharge. Aucun des deux ne ment, et aucun des deux ne te donne l'image complète.

Voici la formulation honnête : MySQL et PostgreSQL sont tous les deux matures, tous les deux éprouvés au combat, et tous les deux capables de faire tourner de sérieuses charges de travail en production. Les différences qui comptent en 2026 sont plus étroites que ce que laisse penser internet — mais elles sont réelles, et elles se rattachent à des choses précises concernant ta charge de travail, ton équipe et ton environnement de déploiement.

Alors passons-les réellement en revue. Pas comme un tableau de scores, mais comme un ensemble de décisions que tu peux prendre pour ta situation précise. Je te dirai où chacun gagne, où chacun te surprend en production, et comment penser ce choix si tu es la personne qui doit vivre avec.

Les deux architectures, et pourquoi elles diffèrent moins que tu ne le penses

Commence par ce qu'elles ont en commun, parce que c'est plus que ce que le discours laisse entendre.

MySQL et PostgreSQL sont tous les deux des systèmes de gestion de bases de données relationnelles client/serveur. Tous les deux tournent comme un processus daemon séparé, écoutent sur un port réseau, parlent un protocole filaire, authentifient les clients et servent du SQL via une connexion. Tous les deux implémentent des transactions ACID avec MVCC (contrôle de concurrence multi-version), ce qui veut dire que les lecteurs ne bloquent pas les writers et que les writers ne bloquent pas les lecteurs. Tous les deux prennent en charge les clés étrangères, les index, les triggers, les procédures stockées, les vues et la réplication. Tous les deux sont open source. Tous les deux ont des décennies d'historique de production derrière eux, et tous les deux ont des offres managées sur tous les grands clouds.

Si tu viens de SQLite — où la base de données est une bibliothèque liée dans ton processus — c'est le point de départ commun. Tous les deux s'attendent à vivre sur une machine qui reste allumée, à être sauvegardés selon un planning et à être joints via le réseau. Tout ce que tu sais déjà sur l'exploitation d'un serveur de base de données s'applique aux deux.

Ce socle commun, c'est pourquoi la question est réellement serrée. Tu ne choisis pas entre deux philosophies de l'informatique. Tu choisis entre deux implémentations de la même idée, avec des priorités différentes gravées dans les détails.

Et c'est dans les détails que vivent les vraies différences. Je les réduirais à quatre domaines :

Le système de types. PostgreSQL embarque un ensemble bien plus riche de types natifs — tableaux, ranges, types géométriques, JSONB, UUID, types d'adresses réseau, et plus encore — et il te laisse définir les tiens. Le système de types de MySQL est plus étroit et historiquement plus permissif sur ce qu'il stocke.
Le modèle d'extension. PostgreSQL est conçu pour être étendu in-process. Tu peux charger des extensions comme PostGIS ou pgvector et obtenir des capacités entièrement nouvelles au niveau de la base de données. MySQL a un système de plugins, mais ce n'est pas le même type d'écosystème.
Les valeurs par défaut. PostgreSQL est strict par défaut — les incompatibilités de type lèvent des erreurs, les contraintes sont appliquées, et tu dois choisir de sortir de la correction. MySQL a historiquement été permissif par défaut, et tu dois choisir d'entrer dans la rigueur.
L'écosystème. MySQL est la base de données par défaut pour une énorme tranche du web — en particulier PHP, WordPress et l'hébergement mutualisé. PostgreSQL est la valeur par défaut pour une autre tranche — l'analytique, le géospatial, et les équipes qui veulent faire plus à l'intérieur de la base de données.

Remarque qu'aucun de ces points n'est « l'un est plus rapide ». Les deux sont rapides. Les deux ont des planificateurs de requêtes assez bons pour que la conception de ton schéma et ton indexation comptent plus que le moteur que tu as choisi. Si tu choisis entre ces deux-là à cause de la performance brute, tu optimises la mauvaise chose — et j'y reviendrai.

Le reste de cet article consiste à transformer ces quatre domaines en une décision que tu peux défendre.

Là où MySQL gagne

Commençons par MySQL, parce que la position « MySQL c'est de l'héritage » efface beaucoup de vrais avantages.

Ubiquité et hébergement

C'est le plus grand avantage structurel de MySQL et il n'y a pas photo. Si tu loues un serveur ou un hébergement mutualisé, MySQL (ou son fork, MariaDB) est presque certainement déjà installé et configuré. Si tu montes une base de données managée chez la plupart des fournisseurs cloud, MySQL est l'une des premières options de la liste. Si tu utilises un framework ou un CMS, il y a de très fortes chances que sa base de données par défaut soit MySQL.

Cette ubiquité a un effet cumulatif. Chaque hébergeur sait comment le faire tourner, chaque sysadmin l'a exploité, et chaque tutoriel pour « comment connecter mon app à une base de données » a un onglet MySQL. Quand tu choisis MySQL, tu choisis le chemin de moindre résistance dans un nombre énorme d'environnements de déploiement — et cette réduction de friction vaut du vrai temps et de vrai argent.

L'écosystème PHP et WordPress

WordPress tourne sur MySQL. Drupal, Joomla, Magento et une longue traîne d'applications PHP qui alimentent une fraction significative du web aussi. Si ton travail implique l'un de ceux-là — construire des plugins, maintenir des sites, migrer du contenu, déboguer un thème — tu travailleras avec MySQL que tu l'aies choisi ou non.

Ce n'est pas une niche. WordPress à lui seul fait tourner une part stupéfiante des sites web, et tout l'écosystème autour — hébergement, plugins, agences, freelances — est bâti sur MySQL. Si c'est le monde dans lequel tu travailles, choisir Postgres veut dire te battre contre l'écosystème à chaque projet. MySQL est le bon choix ici non pas parce qu'il est techniquement supérieur, mais parce que c'est la langue natale de la plateforme sur laquelle tu travailles.

Charges simples à forte lecture

Pour une application web conventionnelle — une requête arrive, tu lis quelques lignes, tu affiches une page, occasionnellement tu écris — MySQL est excellent, et il a été réglé pour exactement ce schéma pendant des décennies. C'est un bourreau de travail. Un CMS à forte lecture, un catalogue de produits, un store de sessions, un site de contenu : MySQL gère tout ça sans drame.

La raison pour laquelle MySQL a gagné sa réputation de « rapide » est en grande partie celle-ci : il a été optimisé, tôt et agressivement, pour les charges web à forte lecture et à nombre élevé de connexions qui dominaient internet. Ce n'est pas que MySQL est intrinsèquement plus rapide que Postgres — sous beaucoup de charges de travail, il ne l'est pas — mais il a été conçu en gardant à l'esprit le cas web courant, et ça se voit dans les valeurs par défaut.

Familiarité et outillage

Il y a plus de gens qui connaissent MySQL que de gens qui connaissent Postgres. C'est une considération de recrutement, une considération d'intégration, et une considération du genre « à qui je demande quand ça casse à 3h du matin ». L'écosystème d'outillage de MySQL est énorme — chaque client graphique le prend en charge, chaque ORM le prend en charge, chaque fournisseur cloud le propose, et il y a vingt ans d'archives de réponses Stack Overflow pour chaque message d'erreur que tu rencontreras.

Pour une petite équipe sans spécialiste dédié des bases de données, la familiarité de MySQL est un véritable avantage opérationnel. La meilleure base de données, c'est celle que ton équipe peut exploiter en confiance.

Là où PostgreSQL gagne

Maintenant l'autre côté, avec la même honnêteté.

Rigueur et correction

La posture par défaut de PostgreSQL, c'est que la base de données doit protéger tes données contre ton application. Les types sont appliqués. Les contraintes ne sont pas négociables. Si tu essaies d'insérer une chaîne dans une colonne d'entiers, tu obtiens une erreur, pas une coercition silencieuse. Si tu déclares une clé étrangère, elle est appliquée. Si tu déclares un NOT NULL, ça veut dire NOT NULL.

Ça compte plus que ça n'en a l'air. Dans MySQL, la valeur par défaut historique était permissive — la base acceptait des données douteuses et s'arrangeait plus tard. Ça a changé ; les valeurs par défaut du MySQL moderne sont bien plus strictes, et tu peux configurer la rigueur. Mais l'héritage culturel persiste : MySQL a une longue histoire d'applications qui reposaient sur le fait que la base était indulgente, et une longue histoire de données qui ont été silencieusement saccagées en conséquence.

Si tu veux que la base de données soit la dernière ligne de défense de l'intégrité des données — plutôt que de faire confiance à chaque chemin de code applicatif pour être correct — la rigueur de PostgreSQL est une fonctionnalité. C'est la base de données qui fait son travail.

Des types plus riches

PostgreSQL embarque des types natifs que MySQL n'a pas ou gère moins bien. Les principaux :

JSONB — du JSON binaire avec prise en charge de l'indexation. Tu peux stocker un document et l'interroger avec des index GIN qui rendent les recherches imbriquées rapides. MySQL a aussi un type JSON, et il est capable, mais le JSONB de PostgreSQL avec une indexation appropriée, c'est un autre niveau d'outillage pour les données en forme de document.
Les tableaux — un vrai type tableau, pas une chaîne séparée par des virgules. Tu peux stocker une liste dans une colonne et l'indexer.
Les ranges — int4range, tsrange, et compagnie. Vraiment utiles pour des choses comme les fenêtres de réservation, les périodes de validité et la planification, où « est-ce que cet intervalle chevauche cet autre intervalle » est une requête que tu veux exprimer naturellement.
Les types géométriques et les types réseau — points, lignes, polygones, inet, cidr, macaddr. Si ton domaine touche à l'un de ceux-là, les avoir nativement est un vrai confort.
UUID — natif, avec des fonctions de génération.

Et surtout, PostgreSQL te laisse définir tes propres types et types composites. Si tes données ont une structure que les types intégrés ne capturent pas, tu peux la construire dans le schéma plutôt que de l'encoder en chaîne et la parser dans ton application.

Les extensions

C'est l'avantage le plus distinctif de PostgreSQL. Parce qu'il est conçu pour être étendu in-process, tout un écosystème de capacités a grandi sous forme d'extensions chargeables :

PostGIS — l'étalon-or du travail géospatial. Si tu fais quoi que ce soit de sérieux avec des cartes, des distances ou des requêtes géographiques, PostGIS est la raison de choisir Postgres, point final.
pgvector — stockage de vecteurs et recherche de similarité, devenu fondamental pour les applications d'IA et basées sur les embeddings.
pg_trgm — correspondance floue de texte basée sur les trigrammes.
hstore, uuid-ossp, pgcrypto, et bien d'autres.

Le schéma ici, c'est que la base de données elle-même peut acquérir de nouvelles capacités sans que tu changes ton architecture. Si ton application a besoin d'une capacité qui vit à l'intérieur de la base de données — et plus d'applications que ce qu'on croit en ont besoin — PostgreSQL a plus de chances de l'avoir déjà, ou d'avoir une extension mature qui la fournit.

Indexation avancée

Les deux bases prennent bien en charge les index B-tree. PostgreSQL va plus loin. Il propose des index GIN et GiST pour les données composites et le plein texte, des index BRIN pour les grandes tables ordonnées séquentiellement, des index partiels (indexer uniquement les lignes qui correspondent à une condition), des index d'expression (indexer une valeur calculée) et des filtres de Bloom. Tu peux construire un index sur une fonction, sur un chemin JSON ou sur un sous-ensemble de lignes.

L'effet pratique, c'est que davantage de formes de requêtes peuvent être rendues rapides sans restructurer ton schéma. Quand tu te heurtes à un mur de performance, PostgreSQL te donne plus de leviers à actionner avant de devoir dénormaliser.

Fonctions de fenêtrage et CTEs

Les deux bases prennent en charge les fonctions de fenêtrage et les expressions de table communes dans leurs versions modernes. Les implémentations de PostgreSQL ont historiquement été plus complètes et plus largement utilisées, et la culture autour de Postgres penche davantage vers « exprime-le en SQL ». Les CTEs récursives, les jointures LATERAL et le cadrage de fenêtre avancé sont des choses que les utilisateurs de Postgres utilisent couramment.

Si tu fais beaucoup d'analytique à l'intérieur de la base de données — plutôt que d'exporter vers un entrepôt séparé — ça compte. Postgres est à l'aise pour être à la fois ta base opérationnelle et ta base analytique pendant longtemps avant que tu ne le dépasses.

L'ampleur de l'écosystème

Au-delà des extensions, PostgreSQL est devenu le choix par défaut d'un certain type d'équipe : celles qui veulent pousser la logique dans la base de données, qui se soucient de la correction, et qui construisent sur du Postgres managé chez des fournisseurs qui le proposent comme produit de premier plan. Cette communauté a produit un écosystème profond d'outillage, de guides et de patterns.

Si tu veux que la base de données soit plus qu'un stockage bête — si tu veux qu'elle soit un participant actif de la logique de ton application — Postgres est conçu pour cette vision du monde.

Ce qui te mord vraiment en production

C'est la section que la plupart des comparaisons sautent, et c'est celle qui compte le plus, parce que les différences qui te mordent en production sont rarement celles du marketing.

Jeux de caractères et collation

L'histoire des jeux de caractères et des collations de MySQL a historiquement été une source de vraie douleur. Les anciennes versions de MySQL utilisaient latin1 par défaut ; la transition vers utf8mb4 (qui, de façon déroutante, est l'encodage qui gère réellement tout l'Unicode — le utf8 de MySQL était historiquement une implémentation partielle) a pris des années et a cassé des choses. La collation détermine comment les chaînes se trient et se comparent, et MySQL a un ensemble vaste et déroutant de collations aux noms qui ne rendent pas toujours leur comportement évident.

L'histoire de PostgreSQL est plus simple et plus prévisible. Tu choisis un encodage à la création de la base et une collation, et ça se comporte de façon cohérente. Il a ses propres subtilités — le comportement de la collation peut varier selon les bibliothèques de locale du système d'exploitation, ce qui a causé des surprises lors des mises à niveau — mais c'est moins un champ de mines.

Si tu stockes du texte généré par les utilisateurs dans plusieurs langues, ça vaut le coup de le comprendre avant de t'engager.

Casse et guillemets des identifiants

MySQL est insensible à la casse pour les identifiants sur de nombreuses plateformes, selon le système de fichiers sous-jacent, et il te laisse écrire SELECT * FROM Users et ça marche que la table soit users ou Users. PostgreSQL ramène les identifiants non quotés en minuscules, donc SELECT * FROM Users cherche une table nommée users — et si ta table s'appelle en réalité "Users" (créée avec des guillemets), la requête non quotée ne la trouvera pas.

C'est un piège de migration classique. Du code qui fonctionnait très bien contre MySQL — en mélangeant les casses librement — casse contre Postgres parce que les identifiants ne se résolvent pas comme le développeur s'y attendait. Sois discipliné et utilise partout des identifiants en minuscules et non quotés, mais si tu portes une application existante, tu vas le sentir passer.

Comportement des transactions et du DDL

Les deux bases prennent en charge les transactions. Mais historiquement, le comportement du moteur de stockage de MySQL autour du DDL — le langage de définition de données, comme CREATE TABLE et ALTER TABLE — était différent : beaucoup d'instructions DDL provoquaient un commit implicite et ne pouvaient pas être annulées. Le MySQL moderne (avec InnoDB) a amélioré le DDL transactionnel, mais le comportement hérité a façonné une génération d'outils de migration et d'attentes.

PostgreSQL prend en charge le DDL transactionnel depuis longtemps : tu peux exécuter une série de changements de schéma à l'intérieur d'une transaction, et si quelque chose échoue en cours de route, tout est annulé. Pour les migrations, c'est une propriété de sécurité significative. Une migration échouée dans Postgres laisse ton schéma exactement comme il était ; dans l'ancien MySQL, elle pouvait te laisser à moitié migré et bloqué.

Si ton processus de déploiement exécute des migrations de schéma dans le cadre d'une release, comprends comment chaque base se comporte quand une migration échoue en cours de route. C'est le genre de chose qu'on apprend à ses dépens.

Gestion du JSON

Les deux bases prennent en charge le JSON, et les deux sont capables. Mais les modèles diffèrent de manières qui comptent. Le type JSON de MySQL stocke le JSON dans un format binaire et prend en charge les requêtes par chemin et les colonnes générées. Le JSONB de PostgreSQL stocke une représentation binaire décomposée qui prend en charge l'indexation directement avec GIN, et ses opérateurs JSON sont plus profondément intégrés au planificateur de requêtes.

La différence pratique : dans Postgres, interroger une colonne JSON peut être rendu rapide avec un index comme opération de premier plan. Dans MySQL, tu finis souvent par créer des colonnes générées et les indexer, ce qui marche mais demande plus de cérémonie. Si le JSON est central dans ton modèle de données, c'est une différence d'ergonomie qui compte.

Limites de connexions et pooling

Les deux bases ont un nombre fini de connexions, et les deux tomberont si tu les épuises. Les modes de défaillance diffèrent en saveur mais pas en nature : trop de connexions et tu obtiens des erreurs, des pics de latence, ou une base qui arrête d'accepter de nouveaux clients.

Ce n'est pas une raison de choisir l'un plutôt que l'autre — c'est une raison de prévoir du connection pooling dans les deux cas. Les deux écosystèmes ont des poolers matures, et les deux sont généralement déployés derrière l'un d'eux. Si tu te connectes depuis un environnement serverless à forte concurrence, tu voudras un pooler quel que soit le SGBD que tu choisis. Ne traite pas la limite de connexions par défaut comme un réglage de production.

Chemins de mise à niveau et de migration

Les deux bases ont des chemins de mise à niveau bien compris, et les deux exigent de la planification pour les sauts de version majeure. Aucune n'est une situation « lance et espère ». Lis les notes de version des versions que tu franchis, teste la mise à niveau sur une copie de tes données, et prévois du temps pour les choses dont les notes t'avertissent.

Le sens de la migration entre les deux bases vaut aussi la peine d'être réfléchi. Passer de MySQL à Postgres est un chemin bien balisé avec un outillage établi et des pièges documentés — mais ce n'est pas une opération « clique exporter, clique importer ». Les types, les collations, la casse et le SQL spécifique au vendeur demandent tous de l'attention. Si tu envisages une migration, traite-la comme un projet, pas comme une tâche.

Le tableau de comparaison

Voici le face-à-face, avec la réserve que « gagner » sur une seule ligne décide rarement toute la question.

Dimension	MySQL	PostgreSQL
Architecture	SGBD client/serveur	SGBD client/serveur
Posture par défaut	Historiquement permissive, désormais plus stricte	Stricte par défaut
Système de types	Types conventionnels, prise en charge du JSON	Types riches : JSONB, tableaux, ranges, UUID, géométriques
Modèle d'extension	Système de plugins	Extensions in-process (PostGIS, pgvector, ...)
Indexation	B-tree, plein texte, spatial (selon le moteur)	B-tree, GIN, GiST, BRIN, partiels, expressions
Fonctions de fenêtrage / CTEs	Prises en charge	Prises en charge, largement utilisées, plus complètes
JSON	Type `JSON`, colonnes générées	`JSONB` avec indexation GIN native
Casse des identifiants	Insensible à la casse sur de nombreuses plateformes	Ramène les identifiants non quotés en minuscules
DDL transactionnel	Amélioré avec InnoDB, historiquement limité	Prise en charge de longue date
Jeux de caractères	Historiquement chaotiques (`latin1` → `utf8mb4`)	Plus simples, cohérents
Réplication	Intégrée, largement déployée	Streaming intégré + logique
Écosystème	PHP, WordPress, hébergement mutualisé, apps web	Analytique, géospatial, équipes focalisées sur la correction
Offres managées	Partout	Partout
Outillage	Énorme, universel	Vaste, mature
Idéal pour	Apps web, PHP/WordPress, hébergement omniprésent	Données complexes, extensions, intégrité stricte
Prise en charge Basevolt	Oui	Oui

La lecture honnête de ce tableau : MySQL gagne sur l'ubiquité, l'hébergement et l'adéquation de l'écosystème au web. PostgreSQL gagne sur la richesse des types, l'extensibilité, la rigueur et les capacités de requête avancées. Tout le reste est assez proche pour que la familiarité de ton équipe fasse pencher la balance.

Un cadre de décision pratique

Plutôt qu'un organigramme que tu vas zapper, voici les questions qui déterminent vraiment la réponse. Réponds-y honnêtement pour ta situation.

1. Que privilégie par défaut ta stack existante ?

Si tu es sur WordPress, Drupal, Magento ou un framework PHP dont l'écosystème est bâti sur MySQL, la valeur par défaut est MySQL, et te battre contre elle te coûte du temps à chaque projet. Si tu es sur une stack dont l'outillage penche vers Postgres — ou que tu pars de zéro sans attirance forte — penche vers Postgres. Le chemin de moindre résistance est un facteur légitime, pas une échappatoire.

2. As-tu besoin d'une capacité qui vit dans la base de données ?

Des requêtes géospatiales ? De la recherche vectorielle pour des fonctionnalités d'IA ? De la requête de documents riche avec une indexation appropriée ? De l'analytique avancée avec des fonctions de fenêtrage et des CTEs récursives ? Si la réponse à l'une de ces questions est oui, cette capacité devrait probablement décider ton choix — et le plus souvent elle pointe vers PostgreSQL.

3. À quel point as-tu besoin que la base de données applique la correction ?

Si tu veux que la base de données soit l'autorité finale sur l'intégrité des données — appliquant types, contraintes et relations quoi que fasse l'application — les valeurs par défaut strictes de PostgreSQL sont un avantage qui compte. Si ta couche applicative est la source de vérité et que la base n'est qu'un stockage, la posture plus indulgente de MySQL est moins préoccupante (et le MySQL moderne est de toute façon assez strict pour la plupart des usages).

4. Qui va exploiter ça ?

Si tu as une équipe qui connaît MySQL en profondeur et personne qui connaît Postgres, c'est un vrai coût de basculer. Si ton équipe est à l'aise avec l'un ou l'autre, les mérites techniques pèsent plus lourd. La base de données que ton équipe peut faire tourner, sauvegarder et déboguer en confiance vaut plus qu'un avantage marginal sur les fonctionnalités.

5. Est-ce que tu choisis vraiment, ou est-ce que tu hérites ?

Beaucoup de gens qui posent cette question héritent d'une base de données — elle tourne déjà, elle est déjà en production, et la question est en réalité « devrais-je migrer ? ». Une migration est coûteuse, risquée, et rarement justifiée par la seule envie de fonctionnalités. Si MySQL fonctionne et que ta charge de travail n'a pas besoin de ce que Postgres offre d'unique, reste. Si tu t'es heurté à un mur que seul Postgres franchit, migre délibérément et prévois le budget.

Si tu as répondu « MySQL » aux questions 1, 4 et 5, et « non » aux 2 et 3, utilise MySQL. Si tu as répondu « Postgres » aux 2 ou 3, utilise PostgreSQL. Si c'est vraiment à égalité, choisis celle que ton équipe connaît mieux et réévalue dans un an — les deux sont assez bonnes pour que le choix mauvais-mais-familier batte le choix bon-mais-inconnu.

Utiliser les deux

Voici ce que font réellement beaucoup d'équipes expérimentées : elles utilisent les deux, et le choix n'est pas le « soit l'un soit l'autre » qu'internet laisse croire.

Des configurations courantes que j'ai vues dans la vraie vie :

PostgreSQL comme base de données opérationnelle principale, MySQL pour un composant hérité ou WordPress. Les entreprises qui sont nées d'un site WordPress gardent souvent MySQL pour le CMS et font tourner les nouveaux services sur Postgres. Deux bases de données, deux métiers, une équipe.
MySQL pour l'app web transactionnelle, Postgres pour l'analytique. MySQL sert le chemin des requêtes ; un réplica ou un pipeline ETL alimente Postgres, où vivent les requêtes analytiques et les extensions comme PostGIS ou pgvector.
MySQL pour l'app, SQLite pour les caches locaux et l'edge. Si tu distribues les lectures à l'edge, tu peux avoir MySQL comme source de vérité et des réplicas SQLite proches des utilisateurs — un pattern dont j'ai parlé dans SQLite vs PostgreSQL.
Postgres pour tout ce qui est nouveau, MySQL pour tout ce qui est ancien. La stratégie pragmatique d'évitement de migration : ne retire pas ce qui fonctionne, mais arrête d'y ajouter des choses.

La friction dans n'importe laquelle de ces configurations n'est jamais les bases de données elles-mêmes — c'est l'outillage. Tu te retrouves avec un panneau d'administration pour MySQL et un complètement différent pour Postgres, deux jeux de détails de connexion, et aucun moyen de voir à travers les deux. Les développeurs perdent une quantité surprenante de temps juste à changer de contexte entre les outils de base de données.

C'est l'une des raisons pour lesquelles on a construit BaseVolt pour gérer les deux moteurs à travers la même interface. Pointe-le vers une connexion MySQL ou une connexion Postgres et tu obtiens le même panneau d'administration dans les deux cas — vues grille, galerie, kanban et dashboard, visualisation des relations, et édition en ligne qui n'altère pas ton schéma. Pour les équipes qui font tourner les deux, ça veut dire un outil au lieu de deux, et un seul endroit où regarder quand tu essaies de comprendre tes données.

Si tu pèses l'outillage d'administration pour l'un ou l'autre moteur spécifiquement, j'ai écrit séparément sur les outils d'administration MySQL comparés, et si tu viens d'un client généraliste, ça vaut le coup de savoir ce que tu perdrais en restant avec DBeaver ou TablePlus plutôt qu'avec un panneau conçu pour ça.

Erreurs courantes

Une liste courte, tirée de choses que j'ai vues mal tourner.

Choisir Postgres pour un projet WordPress. Tu passeras le projet à te battre contre un écosystème qui présuppose MySQL. Utilise MySQL, ou accepte la taxe en connaissance de cause.

Choisir MySQL pour une charge de travail qui a besoin de PostGIS ou de pgvector. Si la capacité est centrale dans ton produit, n'essaie pas de la simuler avec des contournements dans MySQL. Choisis la base de données qui a l'outil.

Migrer parce que Postgres est « meilleur ». L'envie de fonctionnalités n'est pas un plan de migration. Migre quand tu t'es heurté à un mur précis, et prévois le budget pour le projet que c'est réellement.

Présumer que les valeurs par défaut permissives de MySQL sont encore les valeurs par défaut. Le MySQL moderne est bien plus strict que sa réputation. Vérifie ta configuration réelle plutôt que de répéter des conseils de 2012.

Traiter la limite de connexions par défaut de l'une ou l'autre base comme prête pour la production. Les deux ont besoin de pooling sous une charge réelle. Ce n'est pas un différenciateur — c'est un piège partagé.

Choisir sur la base d'un benchmark trouvé en ligne. Les benchmarks mesurent la charge de travail du benchmark, pas la tienne. Ton schéma, tes index et tes patterns d'accès dominent.

Ignorer les différences de casse et de collation jusqu'au jour de la migration. Si tu risques un jour de passer de l'une à l'autre, écris des identifiants en minuscules et non quotés, et réfléchis à l'encodage maintenant. C'est gratuit à faire et cher à corriger.

En résumé

MySQL et PostgreSQL sont tous les deux excellents, tous les deux matures, et tous les deux capables de faire tourner de sérieux systèmes de production en 2026. Les différences qui comptent sont plus étroites que ne le suggère la dispute, et la dispute est généralement portée par celle que la personne a le plus utilisée.

La version courte :

MySQL quand tu es dans le monde PHP/WordPress/hébergement web, quand l'ubiquité et l'adéquation de l'écosystème comptent, quand tu veux le chemin de moindre résistance sur des charges web conventionnelles à forte lecture, et quand ton équipe le connaît bien.
PostgreSQL quand tu as besoin de types plus riches, d'extensions comme PostGIS ou pgvector, d'une intégrité stricte appliquée au niveau de la base, d'une indexation avancée, ou d'analytique qui s'appuie sur les fonctions de fenêtrage et les CTEs.

Aucune de ces deux listes n'est « la bonne réponse ». Ce sont des réponses différentes à des questions différentes, et la compétence, c'est de savoir quelle question tu poses réellement.

Et pour beaucoup d'équipes, la réponse honnête est que tu finiras avec les deux — MySQL là où l'écosystème t'a tiré, Postgres là où la capacité l'a fait — ce qui est exactement pourquoi un seul panneau d'administration qui parle les deux vaut la peine d'exister. BaseVolt se connecte directement à PostgreSQL, MySQL, SQLite et Cloudflare D1, tourne entièrement sur ta machine et garde tes identifiants en local. Il y a une démo live sur demo.basevolt.app, ou essaie l'offre gratuite — deux sources de données, sans compte requis.

Tu travailles avec MySQL ou Postgres ? Je suis curieux de savoir lequel tu as choisi et ce qui a fait pencher la balance — retrouvez-moi sur X.