Nouveau projet Laravel : la documentation supporte les deux. L'hébergeur mutualisé ne propose que MariaDB. Le développeur principal préfère Postgres pour JSONB et contraintes. Le commercial cite « MySQL c'est plus rapide » sans benchmark.
Pour une application web moderne, le comparatif ne se joue pas sur un slogan — sur le modèle de données et l'écosystème hébergeur.
Forces par usage web
| Usage | MySQL/MariaDB | PostgreSQL |
|---|---|---|
| WordPress / Drupal classique | Natif | Non standard |
| Laravel / Django nouveau projet | OK | Souvent préféré |
| JSON semi-structuré | Type JSON | JSONB indexé |
| Géospatial | Limité | PostGIS |
| Reporting SQL avancé | Correct | CTE, fenêtres forts |
| Hébergement entrée de gamme | Ubiquitaire | Moins fréquent |
MySQL sert bien le CMS web historique. Postgres sert bien le produit applicatif avec logique en base.
Critères techniques qui tranchent
Choisissez MySQL/MariaDB si : stack imposée (WordPress, PrestaShop par défaut), hébergement mutualisé sans Postgres, équipe DBA MySQL existante.
Choisissez PostgreSQL si : contraintes d'intégrité strictes, JSONB, recherche full-text intégrée, analytics SQL, extensions (pgvector, PostGIS).
Hébergement et exploitation
Mutualisé : MariaDB incluse — Postgres absent → MySQL implicite.
VPS : installez les deux ; séparez base et application.
Managé : RDS/Aurora MySQL vs RDS/Scaleway Postgres — comparez sauvegarde point-in-time et prix stockage identiques.
Performance et tuning : le vrai comparatif
MySQL 8 et PostgreSQL 16 bien configurés se valent sur charge OLTP classique. Les écarts apparaissent sur requêtes analytiques, contraintes référentielles strictes, JSON indexé et extensions. Avant de trancher, exportez vos dix requêtes les plus lentes depuis slow query log ou pg_stat_statements et testez-les sur les deux moteurs avec volume représentatif.
Sur mutualisé, MariaDB impose souvent des limites connexion et taille base — vérifiez avant de promettre Postgres en production. Sur VPS, séparez toujours base et application ; co-localiser les deux sur un petit serveur est la cause la plus fréquente de lenteurs « inexpliquées ».
Migrations et dette technique
Changer de moteur en cours de vie coûte semaines de migration schema et tests régression. Sur un nouveau projet, tranchez avant la première migration ORM. WordPress et PrestaShop imposent souvent MySQL/MariaDB — ne promettez pas Postgres « pour la modernité » sans stack compatible. Les ORM masquent parfois des requêtes N+1 qui punissent un moteur plus que l'autre : profilez avant de blâmer la base.
Le sommet : la base qui sert le mieux votre app est celle que vous hébergez correctement
Alignez choix moteur et choix hébergement dans le même atelier.
Décider et avancer sans angle mort
Listez d'abord CMS ou framework imposés et extensions base requises dans un document partagé. Vérifiez l'offre hébergeur : Postgres disponible, version, sauvegarde managée. Prototypez les requêtes critiques sur les deux moteurs si doute persiste. Comparez les hébergeurs base via l'annuaire et le comparateur sur coût stockage et restauration identiques.
Questions fréquentes
WordPress doit-il rester sur MySQL ?
WordPress officiel cible MySQL/MariaDB — Postgres possible via plugins non standard. Pour WordPress pur, MySQL/MariaDB reste le choix rationnel.
PostgreSQL est-il plus « strict » ?
Oui — types, contraintes de clés étrangères et transactions souvent plus rigoureux. Utile pour modèles complexes ; exige migrations plus propres.
MySQL 8 vs PostgreSQL 16 pour SaaS neuf ?
Postgres si JSONB, CTE récursifs, fenêtres analytiques, PostGIS. MySQL si équipe héritage MySQL, hébergement mutualisé économique, ou stack LAMP imposée.
Impact hébergement ?
Mutualisé = MySQL/MariaDB presque toujours. VPS/cloud = les deux ; Postgres managé courant pour SaaS modernes.
MySQL ou PostgreSQL : la base qui sert le mieux votre application web est celle que votre stack et votre hébergeur supportent sans contorsion.