MySQL vs PostgreSQL : lequel choisir en 2026 ?

MySQL et PostgreSQL sont les deux systèmes de gestion de bases de données (SGBD) relationnels open source les plus répandus. Tous deux sont matures, gratuits, robustes et capables de faire tourner des applications de toute taille. Le choix entre les deux relève rarement d’une supériorité absolue : il dépend du contexte, de l’équipe et des besoins du projet. Ce comparatif passe en revue leurs différences réelles, sans parti pris, pour vous aider à décider.

Deux philosophies

Historiquement, MySQL s’est fait connaître pour sa rapidité et sa simplicité, porté par la vague du web et le fameux stack LAMP (Linux, Apache, MySQL, PHP). Il privilégie la facilité de prise en main.

PostgreSQL s’est construit une réputation de rigueur et de richesse fonctionnelle, avec un fort respect des standards SQL et des fonctionnalités avancées. On le décrit souvent comme une base « de développeur » ou « d’ingénieur ». Ces réputations se sont estompées : MySQL a beaucoup progressé côté fonctionnalités, et PostgreSQL côté performances. Les différences subsistent surtout dans les détails.

Les fonctionnalités

PostgreSQL propose historiquement un éventail de fonctionnalités plus large :

Types de requêtes : les expressions de table communes (CTE avec WITH), les fonctions de fenêtrage (OVER, PARTITION BY) et les requêtes récursives y sont anciennes et complètes. MySQL les a ajoutées à partir de la version 8.0, plus tardivement.
Contraintes : PostgreSQL gère les contraintes CHECK complexes et les vérifie strictement de longue date.
Index : PostgreSQL offre plusieurs types d’index spécialisés (GIN, GiST, BRIN) utiles pour la recherche plein texte, les données géographiques ou les tableaux, en plus du B-tree standard.

Voici un exemple de fonction de fenêtrage, désormais supporté par les deux :

SELECT
    nom,
    ville,
    montant,
    RANK() OVER (PARTITION BY ville ORDER BY montant DESC) AS rang
FROM ventes;

MySQL reste très complet pour la grande majorité des besoins applicatifs. L’écart de fonctionnalités ne se ressent vraiment que sur des usages avancés.

Les types de données

C’est un point de différenciation net. PostgreSQL propose un système de types particulièrement riche :

-- Types natifs propres à PostgreSQL
CREATE TABLE evenements (
    id       SERIAL PRIMARY KEY,
    tags     TEXT[],              -- tableau
    donnees  JSONB,               -- JSON binaire indexable
    periode  TSRANGE,             -- intervalle de temps
    reseau   INET                 -- adresse IP
);

Les tableaux, le type JSONB (JSON stocké de façon binaire et indexable), les types intervalles ou réseau sont des atouts pour modéliser des données complexes. On peut même définir ses propres types.

MySQL supporte également le JSON depuis la version 5.7, mais son implémentation est un peu moins riche que le JSONB de PostgreSQL en matière d’indexation et d’opérateurs. Pour du relationnel classique, les deux couvrent largement les besoins avec VARCHAR, INT, DECIMAL, DATE, etc.

Les performances

Comparer les performances brutes est délicat, car tout dépend de la charge, du schéma, de la configuration et de la version. Quelques tendances générales, à prendre avec prudence :

Sur des lectures simples et concurrentes en grand nombre, MySQL avec le moteur InnoDB a longtemps eu une réputation de rapidité.
Sur des requêtes complexes, des jointures nombreuses ou des écritures concurrentes lourdes, PostgreSQL est souvent salué pour la qualité de son planificateur de requêtes et sa gestion de la concurrence (via le mécanisme MVCC).

Dans les faits, les deux SGBD tiennent des charges considérables une fois correctement configurés et indexés. Pour la plupart des projets, la performance ne sera pas le facteur décisif : un schéma mal conçu ou des index absents pèsent bien plus que le choix du moteur. Notre guide sur les index SQL montre pourquoi l’optimisation prime souvent sur le SGBD.

L’extensibilité

PostgreSQL brille par son architecture extensible. Des extensions ajoutent des capacités entières sans changer de base :

-- Activer l'extension de données géographiques
CREATE EXTENSION postgis;

-- Activer la recherche par similarité de texte
CREATE EXTENSION pg_trgm;

PostGIS, par exemple, en fait l’une des références pour les données géospatiales. Cet écosystème d’extensions est un argument fort pour les projets aux besoins spécifiques. MySQL est moins extensible en ce sens, mais propose un système de moteurs de stockage interchangeables (InnoDB par défaut, MyISAM, Memory…), ce qui est une forme de flexibilité différente.

Les licences

Les deux sont open source et gratuits, mais sous des licences distinctes :

PostgreSQL est distribué sous la licence PostgreSQL, une licence permissive proche de BSD/MIT. Très libre d’usage, y compris commercial.
MySQL suit un modèle à double licence : GPL pour l’édition Community, et une licence commerciale payante proposée par Oracle pour certains usages. Son appartenance à Oracle a d’ailleurs motivé la création du fork MariaDB, sous licence GPL, resté proche de MySQL.

Pour un projet open source ou commercial standard, les deux restent utilisables gratuitement. Les entreprises sensibles à la gouvernance apprécient parfois la neutralité de PostgreSQL, porté par une communauté et non par un éditeur unique.

Cas d’usage typiques

Quelques repères pour orienter le choix, sans en faire une règle absolue :

MySQL / MariaDB conviennent bien pour :

les applications web classiques et les CMS (WordPress, par exemple, s’appuie sur MySQL) ;
les projets où l’hébergement mutualisé est courant, MySQL y étant quasi universel ;
les équipes qui cherchent une prise en main immédiate.

PostgreSQL est souvent préféré pour :

les applications aux requêtes analytiques complexes ;
les projets manipulant des données géospatiales, du JSON avancé ou des types personnalisés ;
les systèmes exigeant une conformité SQL stricte et une forte intégrité.

Migrer de l’un à l’autre

Migrer entre les deux est possible mais rarement trivial. Le SQL de base (SELECT, INSERT, jointures) est largement portable, mais les différences se nichent dans les détails :

l’auto-incrément s’écrit AUTO_INCREMENT en MySQL, SERIAL ou GENERATED AS IDENTITY en PostgreSQL ;
certaines fonctions (dates, chaînes) portent des noms différents ;
les types spécifiques (tableaux, JSONB, ENUM) demandent une adaptation.

-- MySQL
CREATE TABLE t (id INT AUTO_INCREMENT PRIMARY KEY);

-- PostgreSQL équivalent
CREATE TABLE t (id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY);

Des outils d’aide à la migration existent (comme pgloader pour aller vers PostgreSQL), mais toute migration réelle demande de tester requêtes et code applicatif.

Conclusion nuancée

Il n’y a pas de gagnant universel. MySQL séduit par sa simplicité, son omniprésence chez les hébergeurs et sa rapidité sur les cas courants. PostgreSQL convainc par sa richesse fonctionnelle, son extensibilité et sa rigueur. Pour un premier projet web, MySQL est un choix sûr et facile. Pour un projet aux besoins de données complexes ou évolutifs, PostgreSQL offre plus de marge. Dans les deux cas, vous apprendrez le même SQL fondamental : la compétence est largement transférable, et c’est là l’essentiel.