Comparez MongoDB et PostgreSQL sur la modélisation des données, le requêtage, l'indexation, la scalabilité, les transactions et l’exploitation pour choisir la meilleure base pour votre application.
La question n’est pas « lequel est le meilleur ? » — c’est « quel système convient le mieux à cette charge de travail et à cette équipe ? » MongoDB et PostgreSQL sont tous deux matures et largement adoptés, mais ils optimisent pour des valeurs par défaut différentes : MongoDB pour des données documentaires flexibles et une itération rapide, PostgreSQL pour la modélisation relationnelle, l'expressivité SQL et des garanties d'intégrité fortes.
Le choix importe surtout lorsque votre charge penche nettement dans une direction :
Un modèle mental utile : si vos données sont naturellement un ensemble d'entités avec des relations, PostgreSQL est souvent le choix le plus simple. Si vos données sont naturellement une collection d'enregistrements autonomes qui changent de forme, MongoDB peut réduire les frictions — surtout au début.
Pour garder la comparaison pratique, évaluez les deux options selon les mêmes questions :
Beaucoup d’équipes pratiquent la persistence polyglotte : PostgreSQL pour les données de référence et MongoDB pour le contenu, des modèles de lecture proches du cache, ou des fonctionnalités à base d’événements. L’objectif est de faire moins de compromis sur les parties du système qui comptent le plus — pas la pureté idéologique.
Si vous créez rapidement des services, il peut aussi être judicieux de choisir une plateforme et une architecture qui ne vous verrouillent pas prématurément. Par exemple, Koder.ai (une plateforme vibe-coding qui génère des apps full-stack à partir de chat) parie par défaut sur React + Go + PostgreSQL, un bon « choix sûr » pour les systèmes transactionnels, tout en autorisant des champs semi-structurés via JSONB quand les besoins sont fluides.
Au niveau du modèle de données, MongoDB et PostgreSQL encouragent des façons de penser différentes sur la « forme » de l’application. MongoDB est une base documentaire : vous stockez des documents de type JSON dans des collections. PostgreSQL est une base relationnelle : vous stockez des lignes dans des tables, les reliez par des clés et interrogez ces relations.
Dans MongoDB, un enregistrement typique peut embarquer des données liées directement :
orders
Ceci convient bien aux données hiérarchiques ou « agrégées » que vous récupérez généralement en entier.
Dans PostgreSQL, vous normalisez typiquement en plusieurs tables :
orders (une ligne par commande)order_items (plusieurs lignes par commande)addresses (table optionnelle séparée)Cette structure brille quand vous avez besoin de relations cohérentes et de jointures fréquentes — par exemple pour du reporting croisant clients, produits et commandes.
MongoDB est flexible par défaut : les documents d'une même collection peuvent avoir des champs différents. Cela accélère l'itération, mais laisse aussi plus de place à des formes inconsistantes à moins d'ajouter des règles de validation et de la discipline.
PostgreSQL impose une structure avec des types de colonnes, des contraintes et des clés étrangères. Les changements nécessitent des migrations, mais vous bénéficiez de garde-fous forts pour l'intégrité des données.
Un chemin médian existe : JSONB de PostgreSQL permet de stocker des données semi-structurées dans une table relationnelle. Beaucoup d'équipes utilisent des colonnes pour les champs stables (IDs, timestamps, status) et un JSONB pour les attributs évolutifs — conservant l'intégrité relationnelle tout en autorisant le changement.
MongoDB est fréquemment naturel pour les objets imbriqués, les payloads d'événements et les données de type contenu que vous lisez en bloc. PostgreSQL excelle quand les relations sont de première classe, les jointures sont courantes et les règles de consistance (contraintes) font partie du modèle — pas seulement du code applicatif.
Le ressenti quotidien entre MongoDB et PostgreSQL devient le plus évident au niveau des requêtes : PostgreSQL optimise les opérations ensemblistes sur des tables, tandis que MongoDB optimise le travail sur des documents imbriqués en forme d'objet applicatif.
SQL de PostgreSQL est déclaratif et composable : vous décrivez le jeu de résultats, et le planner décide comment l'obtenir. Cela rend naturelles les filtrations complexes, les groupements, les fonctions fenêtre, les CTE et les transformations multi-étapes — surtout quand les exigences évoluent.
MongoDB utilise typiquement find pour les récupérations simples et le pipeline d'agrégation pour les transformations (filter → project → group → sort, etc.). Le pipeline peut être expressif, mais il est plus procédural — l'ordre compte — et des pipelines très complexes sont parfois plus difficiles à raisonner qu'une instruction SQL unique.
PostgreSQL considère les jointures comme un outil de première classe. Vous pouvez normaliser les données et joindre des tables sans changer la façon de requêter ; le compromis est de penser à la cardinalité des jointures, aux index et parfois au réglage des requêtes.
MongoDB encourage l'embed des données liées quand elles sont souvent lues ensemble (par ex. une commande avec ses lignes). Cela peut éliminer les jointures et simplifier les lectures. L'inconvénient : duplication et mises à jour plus compliquées.
Quand des relations inter-collections sont nécessaires, MongoDB propose $lookup dans les agrégations. Ça marche, mais ce n'est généralement pas aussi ergonomique — ni aussi prévisible en performance à grande échelle — que des jointures relationnelles bien indexées, et cela peut pousser vers des pipelines plus lourds.
PostgreSQL tend à l'emporter pour les charges BI : requêtes ad hoc, jointures exploratoires et reporting sur de nombreuses entités sont simples, et la plupart des outils analytiques parlent SQL nativement.
MongoDB peut supporter le reporting, surtout si vos rapports s'alignent sur les frontières des documents, mais l'analyse multi-entité demande souvent plus de travail de pipeline (ou de l'ETL vers un entrepôt colonne).
Les deux ont des drivers matures, mais l'ergonomie diffère. PostgreSQL profite d'un vaste écosystème d'outils SQL, d'ORM et d'analyseurs de requêtes. MongoDB peut sembler plus naturel dans le code quand vos objets de domaine sont déjà de type JSON — jusqu'à ce que les relations et les besoins de reporting croissent.
La conception du schéma est l'endroit où MongoDB et PostgreSQL diffèrent le plus au quotidien : MongoDB optimise pour façonner les données comme vos objets applicatifs, tandis que PostgreSQL optimise pour façonner des faits reliés.
Dans PostgreSQL, la normalisation est la valeur par défaut : vous scindez les entités en tables et les connectez par des clés étrangères. Cela réduit la duplication et rend les mises à jour cross-entité plus sûres (modifier un nom de client une seule fois).
Dans MongoDB, l'embedding est courant : vous stockez des données liées à l'intérieur d'un même document pour les lire en un seul aller-retour. Par exemple, un document de commande peut embarquer ses lignes.
Le compromis est le coût des mises à jour et de la cohérence. L'embed peut dupliquer des données de référence (titre du produit, snapshot du prix), tandis qu'une normalisation poussée peut entraîner beaucoup de jointures et des APIs bavardes.
Quand les exigences évoluent — ajouter plusieurs adresses de livraison, introduire des champs de taxe optionnels, ou supporter de nouveaux attributs produit — la flexibilité des documents MongoDB absorbe plus facilement de nouveaux champs sans migration lourde.
PostgreSQL peut aussi évoluer en douceur, mais les changements sont explicites : ALTER TABLE, rétro-remplissage, et resserrement progressif des contraintes. Beaucoup d'équipes adoptent une approche « nullable d'abord, contraindre plus tard » pour livrer vite sans perdre l'intégrité à long terme.
Les garde-fous natifs de PostgreSQL (clés étrangères, CHECK, contraintes d'unicité) empêchent des états invalides d'entrer dans la base.
MongoDB repose souvent davantage sur la validation côté application, bien qu'un schéma JSON Schema existe. La différence clef est culturelle : PostgreSQL encourage l'application centrale des invariants ; dans MongoDB, les équipes les implémentent souvent dans les chemins applicatifs et les tests.
Trop d'embed conduit à des documents très volumineux, des points chauds (beaucoup d'écritures sur un seul document) et des mises à jour partielles délicates. Trop de normalisation entraîne des jointures excessives, des APIs bavardes et des surprises de performance.
Règle pratique : embeddez les données qui changent ensemble ; référencez les données qui changent indépendamment.
Les index sont souvent le point où le débat devient concret : la « meilleure » base est fréquemment celle qui peut répondre à vos requêtes les plus courantes avec une latence prévisible.
PostgreSQL utilise par défaut des index B-tree, couvrant de nombreux cas (égalité, intervalles, tri). Quand les patterns d'accès changent, vous disposez aussi d'options spécialisées : GIN (excellent pour les tableaux et la recherche full-text, souvent utilisé avec JSONB), GiST/SP-GiST (géospatial et types personnalisés), et BRIN (tables volumineuses naturellement ordonnées, ex. séries temporelles).
MongoDB s'appuie aussi sur des index de type B-tree pour les recherches et tris courants, avec des types additionnels : multikey pour les tableaux, 2dsphere pour le géospatial, et text pour une recherche textuelle basique.
Cadre pratique : PostgreSQL a plus de primitives d'index pour différents types et opérateurs, tandis que MongoDB met l'accent sur l'accès flexible aux documents et un bon support des champs imbriqués.
Les deux systèmes dépendent fortement des index composés. L'idée centrale est la même : indexer ensemble les champs filtrés pour que le moteur réduise vite l'espace de recherche.
WHERE status = 'active').Les deux bases offrent des capacités full-text intégrées, mais elles conviennent mieux à des expériences de recherche simples.
Si la recherche est une fonctionnalité produit majeure (pertinence complexe, autocomplete, faceting lourd), il est souvent plus propre d'utiliser un moteur de recherche dédié plutôt que d'étirer l'une ou l'autre base hors de son domaine de confort.
Pour les considérations de performance, validez les stratégies d'index avec des plans réels :
EXPLAIN (ANALYZE, BUFFERS) et surveillez les scans séquentiels, estimations erronées et tris coûteux.explain() et analysez les étapes (usage d'index, docs examinés vs retournés).C'est là que les débats « SQL vs MongoDB query language » se calment : l'index gagnant est celui qui réduit le travail sur le chemin que votre application exécute réellement.
Les transactions ne sont pas qu'une case à cocher — elles déterminent les défaillances que votre application peut encaisser sans corrompre les données. ACID signifie généralement : opérations atomiques, validité des données, isolation face aux accès concurrents, et durabilité après crash.
PostgreSQL est construit autour de transactions multi-instructions et multi-tables. Vous pouvez modéliser des workflows comme « créer commande → réserver inventaire → débiter paiement → écrire journal » en une unité, en vous appuyant sur des garanties solides et des fonctionnalités mûres (contraintes, clés étrangères, triggers).
Pour la concurrence, PostgreSQL utilise MVCC : les lecteurs ne bloquent pas les écrivains et vice versa, et les niveaux d'isolation (Read Committed, Repeatable Read, Serializable) permettent de choisir le degré de prévention des anomalies.
MongoDB fournit l'atomicité au niveau du document unique par défaut, idéal quand vous embeddez et pouvez garder les mises à jour dans un seul document. Il supporte aussi les transactions multi-documents (réplica sets et clusters sharded), ce qui permet des workflows de style relationnel — mais avec plus d'overhead et des contraintes pratiques (taille/temps de transaction, coordination).
La consistance dans MongoDB se configure via read concern et write concern. Beaucoup d'applications utilisent des writes en majority et des lectures adaptées pour éviter des rollbacks après un failover.
Les opérations multi-entité font ressortir les différences :
Si vos workflows critiques dépendent d'invariants stricts multi-enregistrements sous concurrence, PostgreSQL paraît souvent plus simple. Si vous pouvez garder les mises à jour critiques dans un document (ou tolérer une réconciliation éventuelle), MongoDB peut être un bon choix.
Les différences de performance tiennent moins au « moteur » qu'à l'adéquation du modèle de données aux patterns d'accès — et à la quantité de travail que la base de données doit faire par requête.
Les systèmes lecture-lourde récompensent les designs qui minimisent les allers-retours et le travail côté serveur. MongoDB peut être très rapide quand une requête mappe sur une seule lecture de document (ou un scan d'index étroit) et que le document n'est pas surdimensionné.
Les systèmes écriture-lourde bottleneck souvent sur la maintenance des index, l'amplification d'écriture et les réglages de durabilité. PostgreSQL peut très bien performer avec des lignes étroites, des index choisis et des écritures en batch ; MongoDB peut aussi exceller avec des patterns append-only, mais les gros documents mis à jour fréquemment peuvent coûter cher.
Les charges mixtes exposent la contention : mises à jour touchant des index chauds, pression de verrouillage et churn cache. Là encore, les deux bases bénéficient de réduire le « travail extra par requête » (index inutiles, projections larges, requêtes trop bavardes).
La latence p99 est souvent dominée par les requêtes les plus lentes, pas la moyenne. Le débit dépend de l'utilisation efficiente du CPU, de la mémoire et de l'I/O en concurrence.
Benchmarkez équitablement en conservant :
Jointures vs lectures de document : les jointures PostgreSQL sont puissantes mais peuvent devenir coûteuses à grande échelle sans clés de jointure efficaces et prédicats sélectifs. MongoDB évite les jointures quand les données sont embedded, mais paie parfois en documents plus volumineux et données dupliquées.
Taille document/ligne : les performances MongoDB chutent quand les documents grossissent et que la plupart des requêtes n'ont besoin que d'un petit sous-ensemble de champs. Dans PostgreSQL, des lignes larges et de gros blobs JSONB augmentent aussi I/O et pression mémoire.
Maintenance d'index : plus d'index améliorent les lectures — jusqu'à ce qu'ils écrasent les écritures. Les deux systèmes paient un coût par écrit pour mettre à jour chaque index, donc gardez les index alignés sur les vrais patterns de requête.
Créez un petit harness qui rejoue vos 5–10 endpoints ou requêtes principaux avec une concurrence et des distributions de données réalistes. Commencez par un baseline, puis variez un élément à la fois (jeu d'index, embedding, JSONB vs tables normalisées). Conservez la checklist dans un repo et itérez — ne vous fiez pas aux benchmarks synthétiques mono-requête.
La HA et la montée en charge ne se réduisent pas à « activer la réplication » — ce sont des choix de conception affectant le schéma, les patterns de requête et la charge opérationnelle. Le chemin le plus rapide vers la croissance est d'aligner les mécanismes de scalabilité sur vos patterns d'accès dominants (lecture-lourde, écriture-lourde, séries temporelles, multi-tenant, etc.).
MongoDB utilise couramment des replica sets : un primaire accepte les écritures, les secondaires répliquent l'oplog, et une élection promeut un nouveau primaire en cas de panne. Ce modèle est simple pour la HA, mais prévoyez :
PostgreSQL s'appuie typiquement sur la réplication en streaming (physique), souvent avec un primaire et des standbys. Le basculement est généralement orchestré par des outils (services managés, Patroni, etc.) et les compromis incluent :
Sharding MongoDB est natif et peut répartir lectures et écritures sur des shards. Le prix à payer est la complexité opérationnelle : choix de la clé de shard, éviter les hotspots, migrations de chunks, et coûts des requêtes cross-shard.
PostgreSQL scale verticalement très bien, et horizontalement de façon plus sélective. Patterns courants : read scaling via replicas et write scaling via :
Avant de vous engager, modélisez vos requêtes futures : quels champs sont filtrés le plus, quels tris sont requis, et ce qui doit être transactionnel. Un design adapté aujourd'hui mais qui force des fan-outs cross-shard, des partitions chaudes ou une réplication trop synchrone va se retrouver bottlenecké plus tôt que prévu.
Le travail opérationnel est l'endroit où « MongoDB vs PostgreSQL » cesse d'être seulement une question de fonctionnalités et devient une question d'habitudes : comment vous sauvegardez, à quelle vitesse vous restaurez, et avec quelle confiance vous changez de version.
PostgreSQL utilise un mix de sauvegardes logiques et physiques :
pg_dump/pg_restore sont flexibles (restauration par table, portabilité) mais peuvent être lents sur de grands jeux.pg_basebackup) + archivage WAL permettent une récupération point-in-time. C'est la voie habituelle pour obtenir un RPO faible (minutes ou moins) et un RTO prévisible.MongoDB aborde cela via des outils et des snapshots :
mongodump/mongorestore sont simples mais peuvent peiner à l'échelle ou avec des RTO serrés.Pour les deux systèmes, définissez RPO/RTO explicitement, puis testez régulièrement les restaurations. Une « sauvegarde » jamais restaurée n'est que des données stockées.
Surveillez les symptômes corrélant fortement à la douleur utilisateur :
pg_stat_statements, auto_explain et logs de requêtes lentes pour Postgres ; profiler et logs lents pour MongoDB.Suivez aussi la santé du stockage : progression du vacuum et bloat pour PostgreSQL ; évictions de cache, défauts de page et impact des builds d'index pour MongoDB.
Les montées de version majeures PostgreSQL impliquent souvent pg_upgrade ou des cutovers par réplication logique ; planifiez la compatibilité des extensions et des fenêtres d'indisponibilité. Les upgrades MongoDB suivent généralement des procédures rolling, en surveillant le Feature Compatibility Version (FCV), la construction d'index et (si sharded) l'équilibrage des chunks.
En pratique, les équipes s'appuient sur des services managés (Atlas, Postgres managés cloud) ou sur l'automatisation via Terraform/Ansible et opérateurs Kubernetes. La question clé n'est pas « peut-on automatiser ? » mais si votre équipe est prête à posséder les runbooks, les signaux on-call et les drills de restauration.
Si vous générez des services rapidement (par ex. via Koder.ai pour déployer plusieurs environnements), standardisez tôt les choix opérationnels — stratégie de sauvegarde, workflow de migration, approche de rollback — pour que la vitesse ne devienne pas fragilité.
La sécurité n'est pas simplement « activer l'authentification ». Pour MongoDB comme pour PostgreSQL, la question pratique est : comment appliquer le principe du moindre privilège, faire tourner les identifiants, et prouver (à vous-même ou à un auditeur) qui a accédé à quelles données et quand.
Les deux bases supportent une authentification forte et un contrôle d'accès basé sur les rôles (RBAC), mais l'ergonomie diffère.
Le modèle PostgreSQL s'articule autour d'utilisateurs/roles, de grants sur schémas/tables/vues et de privilèges SQL prévisibles. Il mappe bien à des rôles séparés pour applications (écriture) et analystes (lecture), souvent via des replicas en lecture.
Le RBAC de MongoDB est mature aussi, avec des privilèges scindés par base et collection, et des options plus fines selon le déploiement. Il convient quand on raisonne déjà en termes « le service X peut lire/écrire la collection Y ».
Pattern least-privilege utile dans les deux cas :
Traitez TLS comme obligatoire. Imposer au niveau driver et serveur, et désactiver les versions de protocole anciennes.
Pour le chiffrement au repos, les capacités varient selon le modèle de déploiement :
Pour SOC 2, ISO 27001, HIPAA, PCI, vous aurez besoin d’une histoire claire d'audit et de rétention : logs de connexions, changements DDL, modifications de privilèges et accès aux tables/collections sensibles. La gouvernance inclut aussi la classification des données (PII ?), les politiques de rétention et des process documentés de réponse aux incidents.
Approche pragmatique : décidez tôt quels événements capturer (auth, actions admin, accès datasets sensibles) et centralisez les logs dans un SIEM.
La plupart des failles réelles concernent les identifiants et la connectivité, pas la syntaxe des requêtes.
Bien fait, MongoDB et PostgreSQL peuvent satisfaire des exigences de sécurité strictes — la différence est plutôt dans le modèle qui correspond le mieux aux patterns d'accès et aux attentes d'audit de votre organisation.
Le coût n'est rarement « juste la base ». Pour MongoDB vs PostgreSQL, le TCO se répartit typiquement entre consommation de ressources, overhead de durabilité et temps des personnes nécessaires pour garder le système sain.
Compute est souvent la variable la plus importante. Les charges basées sur des jointures, du reporting complexe ou une consistance stricte sollicitent différemment CPU et mémoire que des lectures/écritures orientées document. Stockage dépend non seulement de la taille des données brutes, mais aussi de l'empreinte des index et de toute duplication due à la dénormalisation.
IOPS et latence deviennent un poste quand le working set ne tient pas en mémoire ou que les index sont gros. Des taux d'écriture élevés amplifient aussi l'overhead de sauvegarde (fréquence des snapshots, rétention WAL/oplog, tests de restauration). Enfin, réplicas multiplient les coûts : une configuration HA à 3 nœuds multiplie approximativement compute+stockage, et des replicas cross-region ajoutent réseau et classes de stockage plus élevées.
PostgreSQL est typiquement utilisé en open-source, tandis que les déploiements MongoDB varient entre builds communautaires et offres commerciales. Les services managés pour l'un ou l'autre peuvent transférer du temps d'opération vers un prix unitaire plus élevé. Le support payant a de la valeur pour la réponse aux incidents et le tuning, mais le ROI dépend de l'expérience et de la tolérance au risque de votre équipe.
L'effort opérationnel se traduit en salaire et coût d'opportunité : migrations de schéma, tuning d'index, régressions de requêtes, capacity planning, fatigue on-call et travail de conformité. Si votre organisation maîtrise déjà bien PostgreSQL, changer de moteur peut coûter plus cher que la facture infra (et inversement).
Choisir entre une base documentaire et relationnelle porte moins sur la vitesse brute que sur le comportement des données face au changement, le degré d'intégrité à faire appliquer, et la façon dont l'équipe veut interroger.
MongoDB brille souvent dans les domaines centrés sur les documents où « l'objet » ressemble naturellement à un JSON imbriqué et évolue souvent :
PostgreSQL est généralement plus sûr quand l'intégrité relationnelle et SQL expressif sont essentiels :
CHECK), plus transactions ACIDJSONBUne séparation pragmatique : gardez les entités autoritatives et lourdes en contraintes dans PostgreSQL, et stockez les documents flexibles d'interaction ou de contenu dans MongoDB.
Exemples : commandes/paiements en Postgres ; descriptions produit, blobs de personnalisation, événements clickstream ou projections mises en cache dans MongoDB. Utilisez des IDs immuables et un pattern outbox/event pour synchroniser, et traitez chaque système comme source de vérité d’un type d’entité.
| Besoin | Préfère MongoDB | Préfère PostgreSQL |
|---|---|---|
| Forme des données change souvent | ✅ | ➖ |
| Jointures complexes & reporting SQL | ➖ | ✅ |
| Intégrité relationnelle stricte | ➖ | ✅ |
| Stocker des documents imbriqués tels quels | ✅ | ✅ (JSONB) |
| Équipe/outils centrés SQL | ➖ | ✅ |
Si vous voulez réduire la charge décisionnelle tout en livrant vite, choisissez un bon défaut et gardez une porte de sortie : commencez par Postgres pour les entités cœur, réservez MongoDB aux domaines clairement documentaires, et validez avec des plans de requêtes réels.
Pour planifier une migration (ou l'ajout d'un second store), voyez /blog/database-migration-checklist.
Commencez par faire correspondre la base de données à votre charge de travail et à votre équipe :
Si différentes parties du système ont des besoins différents, une option hybride est valide.
Une règle empirique courante :
Validez ensuite avec vos requêtes et schémas de mise à jour les plus fréquents.
MongoDB stocke naturellement des objets imbriqués, donc une seule lecture peut retourner un agrégat entier (par exemple, une commande avec ses lignes imbriquées). Cela réduit les allers-retours et simplifie l'itération rapide.
Le compromis est la duplication et des mises à jour plus complexes, notamment si la même information imbriquée doit être modifiée dans de nombreux documents.
PostgreSQL fait respecter la correction au niveau de la base :
CHECK et UNIQUE pour empêcher des états invalidesCela réduit les risques qu'une donnée incohérente s'infiltre via un chemin de code oublié et facilite le raisonnement sur des règles métier concurrentes à long terme.
Oui — JSONB est souvent le « chemin du milieu ». Un modèle courant est :
JSONBJSONBCela conserve l'intégrité relationnelle tout en autorisant des attributs flexibles.
PostgreSQL considère les jointures comme primitives et est généralement plus ergonomique pour les requêtes multi-entités et l'analyse ad hoc.
MongoDB évite souvent les jointures en encourageant l'embedding. Quand des jointures entre collections sont nécessaires, $lookup peut faire le travail, mais des pipelines d'agrégation complexes deviennent parfois plus difficiles à maintenir et peuvent moins bien monter en charge comparé à des jointures relationnelles bien indexées.
Si le reporting de type BI et les requêtes exploratoires sont des besoins centraux, PostgreSQL l'emporte car :
MongoDB peut bien servir le reporting quand les rapports s'alignent sur les frontières des documents, mais l'analyse multi-entités nécessite souvent plus de travail de pipeline ou d'ETL.
PostgreSQL est « centré transactions » et excelle pour des workflows ACID multi-étapes et multi-tables (par exemple, commande + inventaire + écritures de grand livre).
MongoDB garantit l'atomicité au niveau du document unique par défaut (idéal quand on embed), et propose des transactions multi-documents quand nécessaire — mais avec plus d'overhead et des limites pratiques. Si vos invariants principaux couvrent de nombreux enregistrements sous concurrence, PostgreSQL est souvent plus simple.
Comparez avec vos requêtes réelles et inspectez les plans d'exécution :
EXPLAIN (ANALYZE, BUFFERS) pour détecter les scans séquentiels, les estimations erronées et les tris coûteux.explain() et comparez docsExamined vs documents retournés.Dans les deux systèmes, les index composés et la sélectivité comptent, et trop d'index peuvent écraser les performances en écriture.
Oui, c'est courant. Un partage pragmatique :
Pour que cela reste gérable, définissez une seule source de vérité par entité, utilisez des IDs immuables et synchronisez via des patterns comme outbox/events. Pour planifier des changements, la checklist à /blog/database-migration-checklist aide à structurer la migration.