Le troll est clos : les deux sont excellents
PostgreSQL et MySQL font tourner, à eux deux, l'essentiel du web, et les deux s'installent en cinq minutes sur un VPS. La vraie question n'est pas « lequel est le meilleur » mais « lequel correspond à votre application ». Voici notre grille, nourrie de milliers de VPS observés en production.
PostgreSQL brille quand
- Les données sont complexes : JSONB indexé, tableaux, types géographiques via PostGIS, recherche plein texte native. Ce qui prend trois tables et une jointure en MySQL tient souvent dans une colonne PostgreSQL.
- Les requêtes sont sophistiquées : l'optimiseur PostgreSQL gère mieux les jointures profondes, les CTE et le parallélisme.
- L'intégrité compte : transactions DDL, contraintes avancées, MVCC rigoureuse — la base des applications où une écriture perdue coûte de l'argent.
MySQL brille quand
- L'écosystème décide : WordPress, Magento, PrestaShop et des milliers d'applications sont optimisées pour MySQL/MariaDB. Choisir PostgreSQL pour un WordPress, c'est nager à contre-courant.
- La charge est simple et massive : lectures par clé primaire à très haut débit — le territoire historique d'InnoDB.
- L'équipe le connaît déjà : un MySQL bien administré bat un PostgreSQL subi, et inversement.
Les chiffres sur notre banc d'essai
Même VPS Quantum (16 vCore, 64 GB), tuning équivalent, NVMe Gen4 :
| Test | PostgreSQL 16 | MySQL 8.4 |
|---|---|---|
| Lecture simple (point select) | 310 000 qps | 365 000 qps |
| Mixte lecture/écriture (oltp) | 24 500 tps | 21 800 tps |
| Requête analytique (agrégats, 50 M lignes) | 4,2 s | 11,8 s |
Lecture : MySQL devant en lecture pure, PostgreSQL devant dès que les écritures et la complexité entrent en jeu. Les deux pulvérisent leurs propres chiffres d'il y a dix ans.
Le tuning qui compte plus que le choix
Un mauvais réglage coûte plus cher que le mauvais moteur. Les deux lignes qui changent tout, sur un VPS de 16 GB :
# PostgreSQL : shared_buffers ≈ 25 % de la RAM
shared_buffers = 4GB
effective_cache_size = 12GB
# MySQL : le buffer pool InnoDB ≈ 60-70 % de la RAM
innodb_buffer_pool_size = 10GEt surtout : la base doit tenir en RAM, ou le stockage doit suivre. Sur du NVMe Gen4 à 1 M IOPS, même les lectures hors cache restent sous la milliseconde — c'est là que l'infrastructure fait la différence entre deux VPS « identiques sur le papier ».
Notre règle de décision
Nouvelle application, schéma évolutif, données riches → PostgreSQL. Application existante prévue pour MySQL, équipe rompue à MySQL → restez sur MySQL. Et dans le doute, PostgreSQL : on ne nous a jamais rapporté un client qui le regrettait.