PostgreSQL ou MySQL ? Les deux bases de données relationnelles open source les plus utilisées au monde se ressemblent beaucoup, mais elles ne brillent pas dans les mêmes situations. Ce comparatif t’aide à choisir pour ton projet, avec les versions de juillet 2026 : PostgreSQL 18 et MySQL 9.7 LTS.
Choisir entre PostgreSQL ou MySQL est une décision qui engage un projet sur le long terme : changer de base de données une fois l’application en production est un chantier lourd. Pourtant, beaucoup de développeurs choisissent par habitude, ou parce que c’est la base installée par défaut sur leur hébergement. Ce n’est pas forcément un mauvais choix, mais il vaut mieux savoir ce qu’on gagne et ce qu’on perd.
Ce comparatif passe en revue les différences qui comptent vraiment : fonctionnalités SQL, types de données, JSON, performances, outils, hébergement et écosystème. Avec, à chaque fois, des exemples de requêtes pour voir concrètement la différence. À la fin, tu sauras quelle base choisir selon ton projet, et pourquoi.

Pour un site PHP classique, un WordPress ou un hébergement mutualisé : MySQL (ou MariaDB) est le choix naturel. Pour une application aux données complexes, avec du JSON, de la géolocalisation, de l’analyse ou de la recherche vectorielle : PostgreSQL est généralement le meilleur choix. Dans le doute, pour un nouveau projet d’application, PostgreSQL est rarement un regret.
PostgreSQL et MySQL en bref
| PostgreSQL | MySQL | |
|---|---|---|
| — | — | — |
| Version actuelle (juillet 2026) | PostgreSQL 18 (septembre 2025) | MySQL 9.7 LTS (avril 2026) |
| Autre version maintenue | PostgreSQL 14 à 17 | MySQL 8.4 LTS |
| Éditeur | Communauté PostgreSQL (PGDG) | Oracle |
| Licence | Licence PostgreSQL (très permissive) | GPL, avec licence commerciale possible |
| Philosophie | Conformité au standard SQL, extensibilité, rigueur | Simplicité, rapidité, facilité d’exploitation |
| Moteur de stockage | Un seul moteur, intégré | InnoDB par défaut (moteurs interchangeables) |
| Point fort | Fonctionnalités avancées, types riches, extensions | Omniprésence, simplicité, hébergements |
| Fork notable | — | MariaDB |
Point important pour juillet 2026 : MySQL 8.0 n’est plus maintenu depuis avril 2026. Si un de tes projets tourne encore dessus, la migration vers MySQL 8.4 LTS ou 9.7 LTS est à planifier rapidement. Côté MySQL, Oracle publie désormais des versions LTS maintenues plusieurs années, et des versions Innovation trimestrielles pour tester les nouveautés.
La différence de philosophie
Le débat PostgreSQL ou MySQL tient souvent à une différence d’approche.
PostgreSQL se présente comme « la base de données open source la plus avancée ». Elle suit de très près le standard SQL, propose des types de données très riches et se laisse étendre presque à l’infini grâce aux extensions. Elle est stricte : une donnée invalide est refusée, une conversion douteuse provoque une erreur. Cette rigueur protège tes données, au prix d’un peu plus d’exigence.
MySQL a été pensée pour être simple, rapide et facile à exploiter. Elle a conquis le web dans les années 2000 en devenant le « M » de la célèbre pile LAMP (Linux, Apache, MySQL, PHP), et elle reste la base installée par défaut chez presque tous les hébergeurs. Depuis MySQL 8, elle a rattrapé une grande partie de son retard fonctionnel : fonctions de fenêtrage, CTE, contraintes CHECK, JSON.
MariaDB est un fork de MySQL créé en 2009 par l’un de ses fondateurs. Il reste largement compatible avec MySQL et équipe beaucoup d’hébergeurs et de distributions Linux. Ce comparatif parle de MySQL, mais la plupart des remarques s’appliquent aussi à MariaDB, même si les deux projets divergent peu à peu.
Comparatif des fonctionnalités SQL
Côté SQL « classique » (jointures, agrégations, transactions), PostgreSQL ou MySQL font tous les deux très bien le travail. Les différences apparaissent sur les fonctionnalités avancées.
| Fonctionnalité | PostgreSQL | MySQL |
|---|---|---|
| — | — | — |
Jointures, GROUP BY, sous-requêtes | ✅ | ✅ |
| Transactions ACID | ✅ | ✅ (InnoDB) |
CTE (WITH) et CTE récursives | ✅ | ✅ depuis 8.0 |
Fonctions de fenêtrage (OVER) | ✅ | ✅ depuis 8.0 |
RETURNING après INSERT / UPDATE / DELETE | ✅ | ❌ |
Index partiels (WHERE dans l’index) | ✅ | ❌ |
Contraintes CHECK | ✅ | ✅ depuis 8.0.16 |
DDL transactionnel (annuler un ALTER TABLE) | ✅ | ❌ |
| Types tableaux, intervalles, réseaux | ✅ | ❌ |
| Extensions (PostGIS, pgvector…) | ✅ | Limitées |
Si les jointures ou les agrégations te posent encore question, révise avec nos guides sur les jointures SQL, GROUP BY et HAVING et les transactions SQL : ces bases sont identiques dans les deux systèmes.
Les mêmes requêtes dans PostgreSQL ou MySQL
Quelques exemples concrets montrent les différences au quotidien.
-- Récupérer l'identifiant d'une ligne insérée
-- PostgreSQL : en une seule requête
INSERT INTO clients (nom, email) VALUES ('Léa', '[email protected]')
RETURNING id, cree_le;
-- MySQL : deux étapes
INSERT INTO clients (nom, email) VALUES ('Léa', '[email protected]');
SELECT LAST_INSERT_ID();
-- Clé primaire auto-incrémentée
-- PostgreSQL (syntaxe standard SQL)
CREATE TABLE clients (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
nom TEXT NOT NULL,
email TEXT NOT NULL UNIQUE
);
-- MySQL
CREATE TABLE clients (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
nom VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL UNIQUE
);
-- "Insérer ou mettre à jour" (upsert)
-- PostgreSQL
INSERT INTO stocks (produit_id, quantite) VALUES (42, 10)
ON CONFLICT (produit_id) DO UPDATE SET quantite = stocks.quantite + EXCLUDED.quantite;
-- MySQL
INSERT INTO stocks (produit_id, quantite) VALUES (42, 10)
ON DUPLICATE KEY UPDATE quantite = quantite + VALUES(quantite);
Note pour MySQL : la fonction VALUES() dans ON DUPLICATE KEY UPDATE est dépréciée au profit d’un alias de ligne (INSERT ... VALUES (...) AS nouv ON DUPLICATE KEY UPDATE quantite = quantite + nouv.quantite). Les deux syntaxes fonctionnent encore, mais préfère l’alias dans un nouveau code.

Le JSON dans PostgreSQL ou MySQL
Les deux bases savent stocker et interroger du JSON, mais PostgreSQL a une longueur d’avance avec son type JSONB, stocké sous forme binaire et indexable très efficacement.
-- PostgreSQL : rechercher dans une colonne JSONB, avec index GIN
CREATE INDEX idx_produits_attributs ON produits USING GIN (attributs);
SELECT nom FROM produits
WHERE attributs @> '{"couleur": "rouge", "taille": "M"}';
-- MySQL : extraire une valeur JSON
SELECT nom FROM produits
WHERE attributs->>'$.couleur' = 'rouge';
MySQL peut indexer des valeurs JSON via des colonnes générées ou des index fonctionnels, ce qui fonctionne bien pour quelques champs connus à l’avance. PostgreSQL permet d’indexer tout le document et de faire des recherches beaucoup plus souples. Si ton application manipule beaucoup de données semi-structurées, c’est un argument fort pour PostgreSQL.
Ce que PostgreSQL 18 apporte
PostgreSQL 18, sorti le 25 septembre 2025, a renforcé plusieurs arguments en sa faveur :
- Les entrées-sorties asynchrones (paramètre
io_method), qui accélèrent les lectures séquentielles et leVACUUM. - La fonction
uuidv7(), qui génère des UUID ordonnés dans le temps, bien plus efficaces dans les index que les UUID aléatoires. - Le « skip scan » sur les index multicolonnes, utile quand la requête ne filtre pas sur la première colonne.
- Les colonnes générées virtuelles, désormais le comportement par défaut.
- Les valeurs
OLDetNEWdansRETURNING, pour récupérer l’avant et l’après d’une modification. - L’authentification OAuth, et l’abandon progressif de l’authentification
md5.
-- PostgreSQL 18 : des UUID ordonnés dans le temps
CREATE TABLE commandes (
id UUID PRIMARY KEY DEFAULT uuidv7(),
total NUMERIC(10, 2) NOT NULL,
cree_le TIMESTAMPTZ DEFAULT now()
);
Performances : PostgreSQL ou MySQL, lequel est plus rapide ?
C’est la question qu’on pose le plus souvent, et la réponse honnête est : ça dépend de la charge de travail, et dans la grande majorité des projets, la différence est négligeable par rapport à la qualité des requêtes et des index.
- Lectures simples très nombreuses (un site de contenu, un blog) : MySQL est historiquement très efficace et simple à optimiser.
- Requêtes complexes, jointures multiples, agrégations, analyse : l’optimiseur de PostgreSQL est généralement plus performant.
- Écritures concurrentes intensives : les deux gèrent très bien la concurrence grâce au MVCC, avec des réglages différents.
Avant de changer de base pour une question de vitesse, vérifie toujours tes index et tes requêtes avec EXPLAIN. Un index manquant coûte bien plus cher que le choix entre PostgreSQL ou MySQL.
Choisir une base de données à partir d’un comparatif de performances trouvé en ligne. Les résultats dépendent énormément du matériel, de la configuration et du type de requêtes testées. Teste plutôt avec tes propres données et tes propres requêtes, sur un environnement proche de la production.
Hébergement, outils et écosystème
| Critère | PostgreSQL | MySQL |
|---|---|---|
| — | — | — |
| Hébergement mutualisé | Proposé par certains hébergeurs | Proposé presque partout |
| WordPress | Non pris en charge nativement | ✅ La base de référence |
| Laravel, Symfony, Django, Rails | ✅ | ✅ |
| Outil graphique de référence | pgAdmin, DBeaver | MySQL Workbench, phpMyAdmin, DBeaver |
| Docker | Image officielle postgres | Image officielle mysql |
| Cloud managé | Proposé par tous les grands fournisseurs | Proposé par tous les grands fournisseurs |
| Extensions phares | PostGIS (géographie), pgvector (IA), TimescaleDB | Moins d’extensions, mais un écosystème d’outils très mûr |
L’argument de l’hébergement reste décisif pour beaucoup de projets PHP : si ton site doit tourner sur un mutualisé classique, MySQL ou MariaDB sont presque toujours disponibles, alors que PostgreSQL ne l’est pas partout. À l’inverse, l’extension pgvector a fait de PostgreSQL une base de choix pour les applications d’intelligence artificielle, au point que des frameworks comme Laravel 13 s’appuient sur elle pour leur recherche sémantique.
Pour lancer l’une ou l’autre en local en une commande, notre antisèche des commandes Docker te montre comment faire, et notre sélection des meilleurs outils de gestion de bases de données t’aidera à choisir une interface graphique.
# PostgreSQL 18 en local
docker run -d --name pg -e POSTGRES_PASSWORD=secret -p 5432:5432 postgres:18
# MySQL 9.7 LTS en local
docker run -d --name mysql -e MYSQL_ROOT_PASSWORD=secret -p 3306:3306 mysql:9.7
Sauvegarde, sécurité et exploitation
Au-delà des fonctionnalités, le quotidien d’une base de données, c’est aussi la sauvegarde, la sécurité et la maintenance. Sur ces points, PostgreSQL ou MySQL offrent des outils équivalents, avec des noms différents.
| Tâche | PostgreSQL | MySQL |
|---|---|---|
| — | — | — |
| Sauvegarde logique | pg_dump / pg_dumpall | mysqldump ou mysqlpump |
| Restauration | pg_restore ou psql | mysql < sauvegarde.sql |
| Réplication | Réplication physique et logique intégrées | Réplication par journal binaire, Group Replication |
| Maintenance régulière | VACUUM et ANALYZE (automatisés par autovacuum) | OPTIMIZE TABLE, ANALYZE TABLE |
| Gestion des droits | Rôles, schémas, sécurité au niveau des lignes | Utilisateurs, rôles depuis MySQL 8 |
# Sauvegarder une base PostgreSQL
pg_dump -U postgres -d boutique -F c -f boutique.dump
# Sauvegarder une base MySQL
mysqldump -u root -p --single-transaction boutique > boutique.sql
PostgreSQL propose une fonctionnalité de sécurité particulièrement intéressante : la sécurité au niveau des lignes (Row Level Security). Elle permet de définir, directement dans la base, quelles lignes chaque utilisateur peut voir ou modifier. C’est très utile pour les applications multi-clients, où chaque client ne doit jamais voir les données des autres. MySQL ne propose pas d’équivalent natif : ce filtrage doit être assuré par l’application.
Quel que soit ton choix entre PostgreSQL ou MySQL, quelques règles restent identiques : ne jamais exposer le port de la base directement sur Internet, créer un utilisateur dédié par application avec les seuls droits nécessaires, chiffrer les connexions si la base est distante, et tester régulièrement la restauration de tes sauvegardes. Une sauvegarde jamais restaurée n’est qu’un espoir.
La question de la licence
On l’oublie souvent, mais la licence peut peser dans le choix entre PostgreSQL ou MySQL, surtout pour une entreprise qui distribue un logiciel.
PostgreSQL est publié sous la licence PostgreSQL, proche des licences MIT et BSD : tu peux l’utiliser, le modifier et l’intégrer dans un produit commercial sans contrainte particulière. Le projet est porté par une communauté et plusieurs entreprises, sans propriétaire unique.
MySQL appartient à Oracle et est distribué sous double licence : GPL pour la version communautaire, et licence commerciale pour ceux qui ne veulent pas des obligations de la GPL. Pour un site web ou une application hébergée, la version communautaire convient parfaitement. Pour un logiciel distribué qui embarque MySQL, il faut vérifier les conditions. C’est d’ailleurs l’une des raisons pour lesquelles MariaDB, sous GPL et indépendant d’Oracle, a été créé.
PostgreSQL ou MySQL : quel choix selon ton projet ?
| Ton projet | Recommandation |
|---|---|
| — | — |
| Site WordPress | MySQL ou MariaDB |
| Site PHP sur hébergement mutualisé | MySQL ou MariaDB |
| Apprentissage du SQL, premiers projets | Les deux conviennent, MySQL est plus présent dans les tutoriels |
| Application métier avec règles complexes | PostgreSQL |
| Données JSON semi-structurées | PostgreSQL (JSONB) |
| Géolocalisation, cartes | PostgreSQL avec PostGIS |
| Recherche sémantique, IA | PostgreSQL avec pgvector |
| Analyse, rapports, statistiques | PostgreSQL |
| Équipe qui maîtrise déjà l’une des deux | Celle que l’équipe connaît |

Utilise un ORM ou une couche d’abstraction (PDO, Eloquent, Doctrine) et évite les fonctions SQL trop spécifiques tant que tu n’en as pas besoin. Si un jour tu dois passer de MySQL à PostgreSQL, la migration sera beaucoup plus simple.
Migrer de MySQL vers PostgreSQL
Si tu envisages de passer de MySQL à PostgreSQL sur un projet existant, sache que c’est faisable, mais que cela demande de la préparation. Les principales différences à anticiper :
- Les types :
TINYINT(1)devientBOOLEAN,DATETIMEdevientTIMESTAMP,AUTO_INCREMENTdevient une colonneIDENTITY. - La casse et les guillemets : MySQL entoure les noms d’accents graves, PostgreSQL de guillemets doubles (
"table"), et met les noms en minuscules s’ils ne sont pas entre guillemets. - Les comparaisons de texte : MySQL est souvent insensible à la casse par défaut, PostgreSQL ne l’est pas. Une recherche
WHERE email = '[email protected]'peut ne plus rien trouver. - Les fonctions spécifiques :
IFNULLdevientCOALESCE,GROUP_CONCATdevientSTRING_AGG,NOW()fonctionne dans les deux.
Des outils comme pgloader automatisent une grande partie du transfert des données. Prévois surtout une phase de tests complète de ton application avant de basculer en production.
FAQ
PostgreSQL ou MySQL : lequel est le plus facile pour débuter ?
MySQL est légèrement plus simple à installer et beaucoup plus présent dans les tutoriels et les hébergements mutualisés. Mais le SQL de base est presque identique : ce que tu apprends sur l’un te sert directement sur l’autre.
Peut-on utiliser PostgreSQL avec PHP ?
Oui, sans difficulté. PDO dispose d’un pilote PostgreSQL (pdo_pgsql), et Laravel comme Symfony prennent PostgreSQL en charge nativement. Il faut seulement vérifier que ton hébergement le propose.
MySQL 8.0 est-il encore utilisable ?
MySQL 8.0 n’est plus maintenu depuis avril 2026 : il ne reçoit plus de correctifs de sécurité. Pour un projet en production, migre vers MySQL 8.4 LTS ou MySQL 9.7 LTS.
Et MariaDB dans tout ça ?
MariaDB est un fork de MySQL, largement compatible, très répandu chez les hébergeurs et dans les distributions Linux. Pour un site PHP ou WordPress, il est un excellent équivalent de MySQL.
Pour conclure ce comparatif PostgreSQL ou MySQL, retiens qu’aucune des deux bases ne te fermera de portes. Apprendre PostgreSQL ou MySQL, c’est avant tout apprendre le SQL, la modélisation et l’indexation : ces compétences se transfèrent d’une base à l’autre en quelques jours.
Si ton équipe hésite encore entre PostgreSQL ou MySQL, faites un petit prototype avec vos vraies données et vos requêtes les plus fréquentes. Une journée de test vaut mieux que des semaines de débat, et le choix entre PostgreSQL ou MySQL s’imposera souvent de lui-même face aux besoins concrets du projet.
PostgreSQL ou MySQL ? Pour une application nouvelle, PostgreSQL ; pour un site PHP classique, MySQL. Et dans tous les cas, des index bien pensés.
PostgreSQL ou MySQL : deux bons choix.
Le meilleur choix entre PostgreSQL ou MySQL reste celui qui sert ton projet.
PostgreSQL ou MySQL : le résumé à retenir
- PostgreSQL ou MySQL : deux bases relationnelles open source solides, sans mauvais choix pour un projet web classique.
- MySQL brille par sa simplicité, son omniprésence chez les hébergeurs et sa place dans l’écosystème WordPress.
- PostgreSQL brille par ses fonctionnalités avancées :
RETURNING, JSONB, index partiels, extensions comme PostGIS et pgvector. - En juillet 2026, les versions de référence sont PostgreSQL 18 et MySQL 9.7 LTS ou 8.4 LTS ; MySQL 8.0 n’est plus maintenu.
- Les performances dépendent surtout de tes index et de tes requêtes, bien plus que du choix entre PostgreSQL ou MySQL.
Si tu hésites encore entre PostgreSQL ou MySQL pour une nouvelle application, choisis PostgreSQL ; pour un site PHP ou WordPress sur un hébergement classique, reste sur MySQL.
Conclusion
Le choix entre PostgreSQL ou MySQL ne doit pas te paralyser : les deux sont fiables, rapides et utilisés par des millions de projets. Choisis selon ton hébergement, ton type de données et les compétences de ton équipe, puis investis dans ce qui compte vraiment : une bonne modélisation, des index adaptés et des requêtes propres. Si tu utilises un framework, notre comparatif Laravel ou Symfony t’aidera à compléter ta pile technique.
Sources
- PostgreSQL 18 : annonce officielle
- MySQL : cycle de vie des versions (endoflife.date)
- Documentation PostgreSQL : types JSON
- Documentation MySQL : INSERT … ON DUPLICATE KEY UPDATE
- pgloader : migrer vers PostgreSQL

