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.

⚖️ Comparatif🐘 PostgreSQL 18 · 🐬 MySQL 9.7 LTS🗄️ SQL⏱️ 15 min de lecture

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.

PostgreSQL ou MySQL : quelle base de données choisir pour ton projet
PostgreSQL ou MySQL : deux bases relationnelles solides, deux philosophies.
⚠️
En une phrase

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

PostgreSQLMySQL
———
Version actuelle (juillet 2026)PostgreSQL 18 (septembre 2025)MySQL 9.7 LTS (avril 2026)
Autre version maintenuePostgreSQL 14 à 17MySQL 8.4 LTS
ÉditeurCommunauté PostgreSQL (PGDG)Oracle
LicenceLicence PostgreSQL (très permissive)GPL, avec licence commerciale possible
PhilosophieConformité au standard SQL, extensibilité, rigueurSimplicité, rapidité, facilité d’exploitation
Moteur de stockageUn seul moteur, intégréInnoDB par défaut (moteurs interchangeables)
Point fortFonctionnalités avancées, types riches, extensionsOmnipré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.

🧠
Et MariaDB ?

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éPostgreSQLMySQL
———
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.

Comparatif PostgreSQL ou MySQL : points forts de chaque base de données
Points forts de PostgreSQL et de MySQL, critère par critère.

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 le VACUUM.
  • 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 OLD et NEW dans RETURNING, 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.

🚫
Fausse bonne idée

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èrePostgreSQLMySQL
———
Hébergement mutualiséProposé par certains hébergeursProposé presque partout
WordPressNon pris en charge nativement✅ La base de référence
Laravel, Symfony, Django, Rails✅✅
Outil graphique de référencepgAdmin, DBeaverMySQL Workbench, phpMyAdmin, DBeaver
DockerImage officielle postgresImage officielle mysql
Cloud managéProposé par tous les grands fournisseursProposé par tous les grands fournisseurs
Extensions pharesPostGIS (géographie), pgvector (IA), TimescaleDBMoins 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âchePostgreSQLMySQL
———
Sauvegarde logiquepg_dump / pg_dumpallmysqldump ou mysqlpump
Restaurationpg_restore ou psqlmysql < sauvegarde.sql
RéplicationRéplication physique et logique intégréesRéplication par journal binaire, Group Replication
Maintenance régulièreVACUUM et ANALYZE (automatisés par autovacuum)OPTIMIZE TABLE, ANALYZE TABLE
Gestion des droitsRôles, schémas, sécurité au niveau des lignesUtilisateurs, 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 projetRecommandation
——
Site WordPressMySQL ou MariaDB
Site PHP sur hébergement mutualiséMySQL ou MariaDB
Apprentissage du SQL, premiers projetsLes deux conviennent, MySQL est plus présent dans les tutoriels
Application métier avec règles complexesPostgreSQL
Données JSON semi-structuréesPostgreSQL (JSONB)
Géolocalisation, cartesPostgreSQL avec PostGIS
Recherche sémantique, IAPostgreSQL avec pgvector
Analyse, rapports, statistiquesPostgreSQL
Équipe qui maîtrise déjà l’une des deuxCelle que l’équipe connaît
PostgreSQL ou MySQL : quelle base choisir selon ton projet
PostgreSQL ou MySQL : la recommandation selon le type de projet.
💡
Le bon réflexe

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) devient BOOLEAN, DATETIME devient TIMESTAMP, AUTO_INCREMENT devient une colonne IDENTITY.
  • 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 : IFNULL devient COALESCE, GROUP_CONCAT devient STRING_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

Comments

No comments yet. Why don’t you start the discussion?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *