PostgreSQL ou MongoDB : comment choisir votre base de données

PostgreSQL est une base de données relationnelle : les données sont organisées en tables aux colonnes typées, reliées par des clés étrangères, et interrogées en SQL. Le schéma est défini à l'avance et garantit l'intégrité des données. Elle est développée depuis plus de trente ans par une communauté indépendante sous une licence libre très permissive.

MongoDB est une base de données orientée documents : chaque enregistrement est un document BSON, proche de JSON, dont la structure peut varier d'un document à l'autre au sein d'une même collection. Le modèle encourage à stocker ensemble les données qui sont lues ensemble, plutôt qu'à les répartir en tables jointes.

Cette différence de modèle est le vrai sujet. Les questions de performance brute sont secondaires : les deux systèmes sont rapides lorsqu'ils sont utilisés pour ce à quoi ils sont conçus, et lents quand on les force à faire le contraire de leur nature.

Si vos données sont fortement reliées entre elles (clients, commandes, produits, factures, stocks) et si vous devez les interroger selon des axes variés, le modèle relationnel est le plus naturel. Les jointures, les contraintes d'intégrité et les transactions multi-tables sont au cœur de PostgreSQL.

Si vos données sont des objets autonomes à structure variable (profils, événements, catalogues hétérogènes, contenus), le modèle document évite de multiplier les tables et les migrations de schéma. MongoDB permet aussi de valider un schéma par collection lorsque la rigueur devient nécessaire.

Notez que PostgreSQL gère très bien les données semi-structurées grâce au type JSONB, indexable et interrogeable. Pour beaucoup de projets, une base relationnelle avec quelques colonnes JSONB couvre le besoin de flexibilité sans renoncer aux garanties relationnelles ni ajouter un second moteur.

Le tableau ci-dessous synthétise les différences les plus importantes pour une décision d'architecture. Les deux systèmes évoluent rapidement et comblent progressivement leurs lacunes respectives ; vérifiez toujours la documentation de la version que vous ciblez avant de conclure.

PostgreSQL applique les propriétés ACID à toutes les opérations, y compris celles qui touchent plusieurs tables. Pour une application financière, une gestion de stock ou tout système où deux écritures doivent réussir ou échouer ensemble, c'est un avantage décisif et sans effort de la part du développeur.

MongoDB garantit l'atomicité au niveau du document, ce qui suffit lorsque le document regroupe toutes les données liées. Les transactions multi-documents existent depuis plusieurs versions, mais elles ont un coût en performance, et leur usage intensif est souvent le signe que le modèle relationnel aurait mieux convenu.

MongoDB a été conçu dès l'origine pour la distribution horizontale : les jeux de réplicas assurent la haute disponibilité et le partitionnement (sharding) répartit les données sur plusieurs serveurs. Cette capacité est intégrée au produit et à son service managé Atlas, sans composant supplémentaire.

PostgreSQL monte d'abord verticalement et par réplicas en lecture, ce qui couvre la très grande majorité des applications d'entreprise. Le partitionnement déclaratif des tables est natif ; la distribution sur plusieurs nœuds passe par des extensions ou des services spécialisés.

Sur le plan de l'exploitation, les deux disposent d'offres managées matures. Le choix d'un hébergeur, la stratégie de sauvegarde et la surveillance pèsent souvent davantage sur la fiabilité réelle que le moteur lui-même, et c'est là que les incidents se produisent.

SQL est une compétence universelle : analystes, développeurs et outils de reporting le parlent. Un projet PostgreSQL bénéficie d'un écosystème immense, avec les ORM, les outils de migration et des extensions comme PostGIS ou pgvector. MongoDB propose des pilotes de qualité pour tous les langages et une expérience très fluide pour les développeurs JavaScript et TypeScript.

La licence mérite attention. PostgreSQL est sous une licence libre permissive sans restriction d'usage. Le serveur communautaire de MongoDB est publié sous SSPL, une licence qui impose des obligations aux fournisseurs qui proposent MongoDB comme service ; cela n'affecte pas l'usage interne, mais peut compter pour un éditeur.

En l'absence de contrainte forte, nous recommandons PostgreSQL comme choix par défaut : il couvre les besoins relationnels et semi-structurés, offre des garanties de cohérence fortes et se marie avec tout l'écosystème. C'est le choix le moins risqué pour une application de gestion, un SaaS ou une API métier.

MongoDB est le bon choix lorsque le modèle document est naturel, que les données sont massives et hétérogènes, ou que l'équipe et l'écosystème existant sont déjà construits autour de lui. Dans les deux cas, ce qui compte est de concevoir le modèle de données avec soin avant d'écrire la première ligne de code.