Choisir un système de gestion de données n’est jamais anodin. Les exemples de base de données les plus répandus dans le développement web — MySQL, MongoDB et PostgreSQL — répondent à des besoins radicalement différents, et une mauvaise décision en début de projet peut coûter des mois de migration. Selon le classement DB-Engines, ces trois solutions dominent le marché mondial : MySQL détient environ 30% des parts, MongoDB autour de 25%, et PostgreSQL près de 20%. Autant dire que la majorité des applications web tournent sur l’un de ces trois moteurs. Comprendre leurs différences techniques, leurs forces réelles et leurs limites concrètes permet de faire un choix éclairé — pas un choix par défaut.
MySQL, MongoDB et PostgreSQL : portrait de trois architectures opposées
MySQL est une base de données relationnelle développée et maintenue par Oracle Corporation. Lancée en 1995, elle repose sur le modèle tabulaire classique : des tables, des lignes, des colonnes, et un langage de requête SQL standardisé. Son architecture est pensée pour la rapidité en lecture, ce qui explique son adoption massive par des plateformes à fort trafic comme WordPress ou Joomla. La simplicité de sa configuration et l’abondance de sa documentation en font un point d’entrée naturel pour les développeurs débutants.
MongoDB, publié en 2009 par MongoDB Inc., prend le contre-pied de cette logique. C’est une base de données NoSQL orientée documents : les données sont stockées sous forme de documents JSON (ou BSON), sans schéma fixe. Cette flexibilité structurelle est précieuse quand les données évoluent vite ou quand leur format varie d’un enregistrement à l’autre. Les applications temps réel, les catalogues produits ou les plateformes de contenu éditorial en tirent un bénéfice direct.
PostgreSQL, géré par le PostgreSQL Global Development Group, occupe un terrain différent. C’est une base relationnelle objet, plus stricte que MySQL sur la conformité aux standards SQL, et dotée de fonctionnalités avancées comme les types de données personnalisés, les index partiels ou le support natif du JSON. Son positionnement vise les projets qui exigent à la fois puissance analytique et fiabilité transactionnelle.
Caractéristiques techniques : ce que les chiffres révèlent vraiment
PostgreSQL affiche une conformité ACID à 100%. ACID désigne les quatre propriétés qui garantissent la fiabilité des transactions : Atomicité, Cohérence, Isolation et Durabilité. En pratique, cela signifie qu’aucune transaction ne peut laisser la base dans un état incohérent, même en cas de panne système. Pour une application bancaire, un ERP ou tout système où l’intégrité des données est non négociable, cette garantie change tout.
MySQL gère aussi les transactions ACID, mais uniquement via le moteur de stockage InnoDB (activé par défaut depuis la version 5.5). Avec le moteur MyISAM, plus ancien, les transactions ne sont pas supportées. Ce détail technique a piégé plus d’un développeur qui pensait bénéficier de toutes les protections transactionnelles sans vérifier la configuration.
MongoDB adopte une approche différente. Pendant longtemps, la base ne supportait pas les transactions multi-documents. Ce support a été introduit avec la version 4.0 en 2018, mais il reste moins mature que sur les deux solutions relationnelles. En revanche, MongoDB excelle sur la scalabilité horizontale : son système de sharding natif permet de répartir les données sur plusieurs serveurs sans reconfiguration majeure, un atout que MySQL et PostgreSQL ne proposent pas aussi facilement nativement.
Sur les performances brutes, MySQL conserve un avantage en lecture simple sur de grands volumes de données structurées. PostgreSQL surpasse les deux autres sur les requêtes complexes impliquant des jointures multiples ou des agrégations analytiques. MongoDB domine sur les insertions massives et les lectures de documents complets sans jointure.
Tableau comparatif des trois systèmes
| Critère | MySQL | MongoDB | PostgreSQL |
|---|---|---|---|
| Type | Relationnel (SQL) | NoSQL (documents) | Relationnel objet (SQL) |
| Conformité ACID | Partielle (InnoDB) | Partielle (v4.0+) | Complète (100%) |
| Scalabilité | Verticale principalement | Horizontale native | Verticale + extensions |
| Schéma | Fixe | Flexible (sans schéma) | Fixe + types avancés |
| Cas d’usage idéal | CMS, e-commerce simple | Applications temps réel, IoT | Finance, analytique, ERP |
| Licence | GPL / Commercial (Oracle) | SSPL / Commercial | PostgreSQL License (libre) |
| Coût serveur | 0 à plusieurs milliers € | Gratuit + Atlas (cloud payant) | Gratuit (open source) |
Forces et faiblesses : ce que les benchmarks ne disent pas
MySQL brille par sa maturité et son écosystème. Des décennies de déploiements en production ont produit une documentation exhaustive, des outils de monitoring éprouvés et une communauté capable de répondre à presque n’importe quel problème. Sa faiblesse principale ? La gestion des données semi-structurées reste laborieuse, et les fonctionnalités avancées de PostgreSQL (comme les fenêtres analytiques ou les types géospatiaux natifs) lui font défaut.
MongoDB séduit par sa flexibilité de modélisation. Pas besoin de définir un schéma rigide avant de commencer à stocker des données — un avantage réel lors des phases d’itération rapide d’un produit. Mais cette liberté a un prix : sans discipline stricte dans la modélisation, les collections MongoDB peuvent rapidement devenir un chaos difficile à requêter. Les jointures entre collections (via $lookup) sont possibles mais coûteuses en performance comparées aux jointures SQL natives.
PostgreSQL cumule les avantages des deux mondes sur certains aspects. Son support du JSONB (JSON binaire) permet de stocker des données semi-structurées avec des performances proches de MongoDB pour les requêtes sur ces champs. Sa conformité aux standards SQL est la plus stricte des trois, ce qui facilite la portabilité du code entre environnements. Son seul vrai inconvénient est sa courbe de configuration : bien paramétrer PostgreSQL pour la production demande plus d’expertise que MySQL.
Quels projets réels utilisent ces bases de données ?
Les exemples de base de données en production illustrent mieux que tout discours théorique les choix des équipes techniques. Facebook a longtemps utilisé MySQL à grande échelle, en développant ses propres extensions pour tenir la charge. WordPress, qui propulse plus de 40% du web mondial, s’appuie exclusivement sur MySQL. Ces cas montrent que MySQL reste une valeur sûre pour les architectures web classiques, à condition de ne pas avoir besoin de requêtes analytiques complexes.
Uber a migré une partie de son infrastructure vers MongoDB pour gérer les données de géolocalisation en temps réel. Adobe et eBay figurent parmi les grands utilisateurs de cette base pour leurs systèmes de gestion de contenu et de catalogues produits. La capacité de MongoDB à stocker des documents de structure variable correspond bien aux besoins de ces plateformes où chaque produit ou utilisateur peut avoir des attributs différents.
PostgreSQL est le choix de référence dans les secteurs réglementés. Apple l’utilise en interne, tout comme Instagram pour certaines parties de son infrastructure. Les entreprises fintech et les éditeurs de logiciels ERP privilégient PostgreSQL précisément pour sa rigueur transactionnelle. Sa licence totalement libre (la PostgreSQL License) est aussi un argument dans les appels d’offres publics où les licences propriétaires posent problème.
Comment choisir entre ces trois solutions sans se tromper
La décision ne se résume pas à une question de popularité ou de tendance. Trois paramètres structurent vraiment le choix : la nature des données, les contraintes de cohérence et les ambitions de scalabilité du projet.
Si les données sont fortement relationnelles — commandes liées à des clients, eux-mêmes liés à des adresses et des factures — une base SQL s’impose. PostgreSQL sera préféré si l’intégrité transactionnelle est critique ou si des requêtes analytiques complexes sont prévues. MySQL conviendra mieux pour un projet web standard avec des lectures fréquentes et des requêtes simples, notamment si l’équipe est déjà familière avec cet environnement.
MongoDB répond à un besoin différent : des données dont la structure évolue fréquemment, un volume d’insertions élevé, ou une architecture distribuée dès le départ. Les projets IoT, les applications de messagerie ou les plateformes d’analyse de logs sont des terrains où MongoDB surpasse ses concurrents relationnels sans discussion.
Une dernière réalité s’impose : de nombreuses architectures modernes utilisent plusieurs bases en parallèle. PostgreSQL pour les données transactionnelles, MongoDB pour les logs ou les événements, et un cache Redis pour les données fréquemment lues. Le vrai choix n’est pas toujours « lequel des trois », mais « lequel pour quelle partie du système ».