Quand choisir MongoDB plutôt que PostgreSQL : grille de décision 2026

« MongoDB ou PostgreSQL ? » est devenu une question plus subtile qu’il y a cinq ans. Le type JSONB de PostgreSQL absorbe 80 à 90 % des cas où l’on aurait choisi MongoDB par réflexe en 2018, avec en bonus les transactions multi-tables, les jointures relationnelles efficaces, et un écosystème SQL ouvert. Ce tutoriel détaille les sept questions de décision qui tranchent vraiment, expose les seuils chiffrés à partir desquels MongoDB devient un meilleur choix, et illustre chaque arbitrage par une situation concrète de production sur MongoDB 8.0 LTS et PostgreSQL 18 (ou 17 LTS si maintenu).

Prérequis

• Connaissance basique des deux moteurs : modèle relationnel SQL d’un côté, modèle documentaire BSON de l’autre.
• Avoir lu, idéalement, le tutoriel Modélisation MongoDB embedded vs referenced.
• Aucune installation requise — ce tutoriel est conceptuel, pas opérationnel.
• Temps estimé : 70 minutes pour traverser les 9 étapes de la grille de décision.

Étape 1 — Le terrain commun en 2026

La première vérité à reconnaître : dans 90 % des projets en démarrage, le choix entre MongoDB et PostgreSQL n’a pas d’impact technique mesurable. Les deux gèrent quelques millions de documents sans difficulté, les deux supportent les indexes secondaires, les deux exposent un mode JSON natif. Le débat « NoSQL vs SQL » qui était brûlant en 2014 s’est largement résolu — PostgreSQL a intégré JSONB et l’a optimisé, MongoDB a ajouté les transactions multi-documents et le typage de schéma déclaratif.

Ce qui reste vraiment pertinent en 2026, c’est de regarder le sommet de la courbe d’usage de votre application : quel sera le profil dominant à l’échelle, pas au démarrage. Le bon choix est celui qui ne devra pas être renversé dans deux ans. La grille qui suit pose sept questions dont les réponses, combinées, donnent un verdict robuste.

Étape 2 — Quatre questions de décision rapides

Avant de plonger dans le détail, quatre questions résolvent déjà 80 % des cas. Si vous répondez « oui » à au moins une d’entre elles, MongoDB est un candidat sérieux. Si vous répondez « non » aux quatre, PostgreSQL est probablement le meilleur choix par défaut.

• Votre schéma change-t-il chaque sprint ? Nouvelles propriétés ajoutées sur un produit toutes les semaines, types de documents qui apparaissent à mesure que le métier évolue.
• Avez-vous des sous-entités de cardinalité ouverte, lues ensemble ? Un profil utilisateur avec un tableau de préférences arbitraires, un article avec des sections variables.
• Vos écritures dépasseront-elles 10 000 ops/seconde soutenues ? Logs métier, événements analytiques, ingestion de capteurs.
• Le sharding horizontal est-il une nécessité prévisible ? Volume cible > 500 Go ou multi-régions actif-actif.

Trois ou quatre oui : MongoDB sans hésiter. Un ou deux oui : regarder la question 6 sur le reporting, qui souvent renverse l’équilibre. Zéro oui : PostgreSQL avec JSONB pour les colonnes flexibles, c’est plus simple et plus solide.

Étape 3 — Cardinalité des écritures

Le seuil empirique au-delà duquel MongoDB devient nettement plus confortable que PostgreSQL pour les écritures pures se situe vers 10 000 ops/seconde soutenues. En dessous, les deux tiennent largement : PostgreSQL absorbe les 5 000 inserts/s sur une table bien partitionnée sans rougir. Au-dessus, MongoDB tire avantage de son journal d’écriture optimisé pour les insertions séquentielles, du per-CPU TCMalloc introduit en 8.0, et de la possibilité de sharder l’ingestion sur plusieurs nœuds primary.

Trois cas typiques où ce critère renverse l’arbitrage : une plateforme d’ingestion d’événements analytics qui collecte plusieurs millions d’événements par jour ; un système de logs centralisés alimenté par des centaines d’agents ; un backend IoT qui reçoit des télémétries de milliers de capteurs. Dans ces trois cas, MongoDB est le choix qui passe à l’échelle sans gymnastique. Dans une application transactionnelle classique (CRM, e-commerce, SaaS B2B), on reste très en deçà du seuil et PostgreSQL est plus que suffisant.

Étape 4 — Évolutivité du schéma

Un schéma qui évolue chaque sprint est le pire ennemi des migrations PostgreSQL. ALTER TABLE ADD COLUMN sur une table de 50 millions de lignes peut tenir plusieurs minutes et exige souvent une fenêtre de maintenance, même avec les améliorations lock-free de Postgres 17 et 18. À l’inverse, MongoDB stocke chaque document indépendamment : ajouter un champ revient à le mettre dans les nouveaux documents et à laisser les anciens sans cette clé.

Ce critère pèse fortement quand le métier itère vite : produits aux attributs variables selon la catégorie, contenu éditorial dont la structure évolue, profils utilisateurs avec des champs ajoutés au gré des features. Pour limiter le coût de cette flexibilité, MongoDB propose une validation déclarative via $jsonSchema — vous gagnez la souplesse documentaire sans abandonner le contrat. PostgreSQL JSONB permet une flexibilité comparable mais avec un coût : les indexes GIN sur JSONB sont moins efficaces que les indexes B-tree natifs MongoDB, surtout sur les requêtes range et tri.

Étape 5 — Transactions multi-tables critiques

Ce critère renverse l’arbitrage dans l’autre sens. Si votre métier est dominé par des transactions impliquant plusieurs tables — comptabilité, paiements, gestion d’inventaire avec mouvements croisés —, PostgreSQL reste l’option naturelle. Son moteur ACID est mature, les transactions imbriquées (savepoints) sont robustes, le triggers et procédures stockées permettent de garantir des invariants au niveau base.

MongoDB supporte les transactions multi-documents depuis la 4.0 et cross-shard depuis la 4.2 — donc disponible et fonctionnel en 2026. Mais avec deux limites pratiques. Une : une transaction MongoDB doit terminer en moins de 60 secondes (transactionLifetimeLimitSeconds), sinon elle est avortée. Deux : l’overhead par transaction est sensible — 30 à 60 % de coût additionnel sur les écritures concernées. Pour un système financier où chaque opération est transactionnelle, PostgreSQL reste plus performant et plus prévisible.

Étape 6 — Reporting et analytics

Ce critère est souvent sous-estimé. PostgreSQL a un avantage écrasant côté reporting : jointures multi-tables performantes, fonctions analytiques SQL (OVER, PARTITION BY, WINDOW), intégration native avec BI tools (Metabase, Apache Superset, Looker). Toute la culture analytique du marché parle SQL — c’est le langage de Tableau, Power BI, dbt.

MongoDB répond avec l’aggregation pipeline qui est plus puissant que SQL sur certains cas (pipelines à branches avec $facet, fenêtrage dynamique) mais moins universel côté outils tiers. La règle pratique : si la moitié des heures d’ingénierie sera consacrée à des dashboards et des rapports cross-collection, PostgreSQL est plus simple. Si l’analytique est secondaire et que l’usage principal est applicatif, MongoDB avec une matérialisation via $merge rattrape largement l’écart.

Étape 7 — Scaling horizontal (sharding)

Le sharding est l’argument historique de MongoDB. Né scale-out dès l’origine, MongoDB propose un mécanisme intégré : choisir une shard key, activer le sharding sur la collection, le moteur distribue automatiquement les chunks entre les shards et route les requêtes via les mongos. PostgreSQL propose Citus (extension rachetée par Microsoft, intégrée à Azure Cosmos DB for PostgreSQL) qui apporte une logique similaire — mais c’est une couche additionnelle, pas un comportement natif.

Quand le sharding est-il vraiment nécessaire ? Au-delà de 500 Go de données chaudes (qui ne tiennent plus en RAM sur une seule machine raisonnable), ou au-delà de 50 000 ops/seconde sur un seul nœud. En dessous de ces seuils, un replica set MongoDB ou un PostgreSQL avec partitionnement par range suffisent. Au-dessus, MongoDB propose la voie la moins frictionnelle : sh.shardCollection("ecom.events", { user_id: "hashed" }), et le moteur fait le reste.

Étape 8 — Stack et compétences équipe

Le critère le plus négligé en ingénierie : les compétences de l’équipe pèsent autant que les caractéristiques techniques. PostgreSQL a deux générations de DBAs et de développeurs SQL sur le marché : trouver quelqu’un capable d’optimiser une requête PostgreSQL prend une heure de recrutement. MongoDB a une communauté plus jeune, plus orientée Node.js et Python — l’expertise existe mais elle est plus rare et plus chère sur les profils seniors.

L’arbitrage pratique : si votre équipe vient du monde Java/.NET avec une culture SQL forte, partir sur PostgreSQL accélérera le développement. Si votre équipe est issue du monde Node.js/JavaScript avec une affinité naturelle pour les objets imbriqués et BSON, MongoDB sera plus naturel. Cette adéquation culturelle n’apparaît dans aucun benchmark mais détermine la qualité du code de production sur deux ans.

Étape 9 — Stack hybride PostgreSQL + MongoDB

Une question récurrente : peut-on utiliser les deux en même temps ? Réponse : oui, c’est possible et parfois optimal — mais c’est aussi le triple piège opérationnel le plus fréquent. Trois pattern d’hybride qui fonctionnent bien.

Pattern 1 — PostgreSQL principal + MongoDB pour les logs/events. PostgreSQL héberge la donnée métier transactionnelle (commandes, comptes, paiements), MongoDB héberge les flux à fort volume non-critiques (audit logs, événements analytics, télémétrie). Chaque base joue sur son terrain de force.

Pattern 2 — PostgreSQL pour le canonical, MongoDB pour le cache de vues. Les données sont écrites dans PostgreSQL (source de vérité), un job réplique régulièrement vers MongoDB des vues dénormalisées optimisées pour la lecture (catalogue produit, profil enrichi). MongoDB n’est plus la source mais sert les écrans à haute fréquence de lecture.

Pattern 3 — MongoDB principal + PostgreSQL pour le reporting. L’inverse : MongoDB stocke le métier (le schéma évolue souvent, les écritures sont massives), PostgreSQL reçoit un export régulier (via Airbyte, Debezium ou un pipeline custom) pour exécuter les dashboards BI. Le coût opérationnel double mais on récolte le meilleur des deux mondes.

Ce qu’il faut éviter : les architectures où la même donnée est écrite des deux côtés en parallèle, avec une logique applicative pour maintenir la cohérence. C’est la garantie de désynchronisations subtiles, de bugs difficiles à reproduire, et d’une dette opérationnelle qui s’accumule. Un seul moteur est source de vérité, le second n’est qu’un reflet — et le sens du flux ne doit jamais s’inverser.

Erreurs fréquentes

FAQ

Q : PostgreSQL JSONB remplace-t-il complètement MongoDB ?
R : Pour 80 à 90 % des cas usuels, oui. Les 10 à 20 % restants tournent autour du sharding horizontal, des écritures massives, et de l’aggregation pipeline plus puissante. Tant qu’un seul de ces axes n’est pas critique, JSONB couvre largement.

Q : MongoDB est-il plus rapide que PostgreSQL en lecture ?
R : Sur un document unique lu par clé primaire, les deux sont équivalents (quelques millisecondes). Sur des lectures qui nécessitent des jointures, PostgreSQL est plus rapide. Sur des lectures qui dépendent d’un schéma profondément imbriqué, MongoDB est plus rapide parce qu’il évite les jointures.

Q : Peut-on migrer de MongoDB vers PostgreSQL plus tard ?
R : Oui, mais c’est non-trivial. Le schéma documentaire doit être éclaté en tables, les références implicites résolues, les indexes recréés. Outils possibles : Airbyte avec un connecteur MongoDB → PostgreSQL, ou un script ETL custom. Compter plusieurs semaines pour une base de production.

Q : Vector search : pgvector ou Atlas Vector Search ?
R : pgvector si vous êtes déjà sur PostgreSQL — l’extension est mature et bien intégrée. Atlas Vector Search si vous êtes sur Atlas — c’est intégré au cluster sans déploiement séparé. Pour des volumes vectoriels très massifs, des spécialistes comme Pinecone ou Qdrant restent pertinents.

Q : Le marché embauche-t-il plus PostgreSQL ou MongoDB ?
R : PostgreSQL est plus demandé dans l’enterprise et les structures financières. MongoDB est plus demandé chez les éditeurs SaaS et les startups orientées produit. Côté salaire, c’est équivalent à séniorité égale, avec un petit avantage MongoDB pour les profils Atlas/Cloud.

Pour aller plus loin

• MongoDB : NoSQL en pratique — point d’entrée du parcours MongoDB.
• Modélisation MongoDB embedded vs referenced — la décision interne au monde documentaire.
• PostgreSQL en pratique — l’autre face du miroir.
• PostgreSQL en surcharge : tuning à 100k req/s — quand PostgreSQL atteint ses limites.
• MongoDB Compare — official PostgreSQL comparison — la position MongoDB Inc.