MongoDB vs PostgreSQL : choisir la bonne base de données en 2026

Comment aborder cette comparaison

Choisissez PostgreSQL lorsque les relations, les contraintes, les transactions et le reporting flexible dominent la charge de travail. Choisissez MongoDB lorsque la plupart des opérations lisent ou mettent à jour des documents autonomes, de taille limitée, dont les champs varient beaucoup. Aucun des deux moteurs n'est universellement plus rapide ou plus simple.

Partez de l'application plutôt que d'une liste de fonctionnalités. Un système de facturation n'échoue pas de la même façon qu'un catalogue de contenu, même si les deux exposent du JSON via une API. La base de données doit rendre ordinaires les opérations les plus difficiles de l'application, pas seulement les rendre possibles.

Évaluez les deux options à partir de cinq questions concrètes :

• Quels enregistrements doivent changer ensemble dans une même transaction ?
• Quelles requêtes traversent les frontières entre entités, et à quelle fréquence changent-elles ?
• Quelles règles doivent rester vraies même si le code applicatif échoue ?
• Jusqu'à quelle taille un enregistrement logique peut-il grandir, et sa collection d'enfants peut-elle croître sans limite ?
• Qui exploitera la base, la restaurera, la réglera et répondra aux incidents ?

PostgreSQL est généralement le choix par défaut le moins risqué pour les comptes SaaS, les permissions, les commandes, la facturation, les stocks, les pistes d'audit, les CRM et les ERP. Ces domaines comportent de nombreuses relations plusieurs-à-plusieurs et des invariants qui s'accordent bien avec les tables, clés étrangères, contraintes d'unicité et SQL.

MongoDB convient souvent aux entrées de contenu, fiches produit avec des attributs propres à chaque client, documents de configuration, charges utiles d'événements et autres agrégats généralement récupérés sous forme d'un seul objet. Sa structure de document flexible peut raccourcir la première implémentation, à condition que l'équipe maîtrise toujours l'évolution du schéma.

Utiliser les deux bases est raisonnable si chacune possède un domaine clairement séparé. Cela coûte cher lorsque la frontière reste floue. Deux stockages impliquent deux systèmes de sauvegarde, deux modèles de supervision, deux configurations de sécurité et un mécanisme de synchronisation. N'acceptez ce coût que si une seule base poserait durablement un problème de modélisation ou de mise à l'échelle.

Modèle de données : documents ou tables relationnelles

MongoDB convient aux données stockables sous forme d'agrégats bornés, tandis que PostgreSQL convient aux données dont la valeur dépend de relations entre entités qui évoluent indépendamment. La différence va bien au-delà de JSON contre lignes, car elle détermine où vivent les règles de cohérence.

Une commande MongoDB peut intégrer son adresse de livraison et ses lignes :

{
  "_id": "order_1042",
  "customerId": "customer_28",
  "status": "paid",
  "shippingAddress": {
    "city": "Austin",
    "country": "US"
  },
  "items": [
    { "productId": "product_7", "quantity": 2, "unitPrice": 19.95 }
  ]
}

Une seule recherche indexée peut renvoyer la commande complète. Une seule mise à jour peut aussi modifier la commande et ses éléments intégrés de manière atomique. C'est intéressant lorsque ces parties ont le même cycle de vie et que le tableau reste borné.

Le modèle PostgreSQL comparable sépare les faits qui ont un sens propre :

CREATE TABLE orders (
    id bigint PRIMARY KEY,
    customer_id bigint NOT NULL REFERENCES customers(id),
    status text NOT NULL,
    placed_at timestamptz NOT NULL
);

CREATE TABLE order_items (
    order_id bigint NOT NULL REFERENCES orders(id),
    product_id bigint NOT NULL REFERENCES products(id),
    quantity integer NOT NULL CHECK (quantity > 0),
    unit_price numeric(12, 2) NOT NULL CHECK (unit_price >= 0),
    PRIMARY KEY (order_id, product_id)
);

Ce modèle facilite le reporting entre commandes et les relations avec les produits. La base peut refuser un article dont la commande ou le produit n'existe pas. Elle permet aussi de modifier un produit indépendamment tout en conservant le prix enregistré lors de l'achat.

L'imbrication convient mal aux collections sans limite, comme tous les événements générés par un compte. Un document qui grossit devient un point chaud d'écriture, consomme davantage de bande passante et finit par atteindre la limite de 16 Mio par document de MongoDB. Stockez plutôt ces événements dans des documents séparés.

La normalisation peut aussi aller trop loin. Répartir un petit objet-valeur entre plusieurs tables ajoute des jointures sans créer d'indépendance utile. Une adresse de livraison enregistrée pour une commande terminée est souvent un instantané historique, pas une référence vivante à l'adresse actuelle du client.

Une règle de modélisation durable consiste à intégrer les données qui changent ensemble et restent bornées. Référencez ou normalisez les données qui changent indépendamment, participent à de nombreuses relations ou grandissent sans plafond prévisible.

Évolution du schéma et intégrité des données

MongoDB facilite l'ajout de champs, tandis que PostgreSQL facilite l'application d'une structure uniforme. Dans les deux systèmes, la sécurité en production dépend de migrations rigoureuses.

Les collections MongoDB peuvent contenir des documents aux champs et types différents. Cette souplesse aide lorsque les attributs varient selon le client ou le type de contenu, mais elle peut aussi produire plusieurs versions incompatibles d'un même concept. Un champ renommé peut laisser d'anciens documents derrière lui, et chaque lecteur doit alors prévoir une logique de repli.

MongoDB prend en charge la validation de collections avec des règles de type JSON Schema. Les équipes peuvent introduire la validation progressivement, compléter les documents existants, puis refuser les nouvelles écritures qui ne respectent pas la structure choisie. Un champ de version du schéma peut aider les traitements à migrer les anciens documents de façon prévisible, sans remplacer la validation.

Les changements PostgreSQL sont explicites. Les équipes ajoutent normalement une colonne nullable, déploient du code qui écrit les anciennes et nouvelles formes si nécessaire, complètent les données par lots contrôlés, valident les données, puis ajoutent des contraintes plus strictes. Les gros index peuvent être créés en parallèle afin de réduire les perturbations d'écriture. Les clés étrangères et certaines contraintes peuvent aussi être introduites par étapes avant validation complète.

Placez dans la base les invariants utiles lorsque le moteur peut les exprimer :

• Utilisez des contraintes d'unicité pour les identifiants, jetons d'idempotence et enregistrements uniques par propriétaire.
• Utilisez des clés étrangères pour les relations qui ne doivent jamais pointer vers des données absentes.
• Utilisez des contraintes CHECK pour les règles locales, comme des quantités positives.
• Utilisez la validation applicative pour les règles contextuelles qui exigent des services distants ou une politique changeant souvent.
• Utilisez des tests pour vérifier le chemin de migration depuis chaque version de schéma prise en charge.

La validation applicative reste nécessaire pour fournir des messages d'erreur utiles et prendre en charge les flux métier. Les contraintes de base de données forment la dernière barrière contre les courses, les chemins de code oubliés, les scripts d'administration et les futurs services qui écriront les mêmes données.

Un schéma flexible doit signifier une variation maîtrisée, pas une variation inconnue. Avant de choisir MongoDB pour itérer plus vite, définissez qui possède la structure des documents, comment les changements incompatibles sont détectés et quand les anciens documents sont réécrits.

Requêtes, jointures et reporting

PostgreSQL est plus direct pour les questions changeantes qui traversent plusieurs entités, tandis que MongoDB est concis lorsqu'une requête suit la frontière d'un document. L'ergonomie des requêtes gagne en importance à mesure que le produit accumule des besoins de reporting.

SQL est déclaratif. Filtres, jointures, regroupements, expressions de table communes, fonctions de fenêtre, sous-requêtes et opérations ensemblistes se combinent sans modifier le modèle stocké. Le planificateur de PostgreSQL choisit les algorithmes de jointure et chemins d'accès à partir des statistiques et index disponibles.

Une requête de chiffre d'affaires sur des commandes normalisées reste lisible :

SELECT
    o.customer_id,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.status = 'paid'
  AND o.placed_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY o.customer_id
ORDER BY revenue DESC;

MongoDB utilise des opérations find directes pour les récupérations simples et un pipeline d'agrégation pour les transformations. Avec des lignes intégrées, le calcul comparable traite les documents en étapes ordonnées :

db.orders.aggregate([
  { $match: { status: "paid", placedAt: { $gte: startDate } } },
  { $unwind: "$items" },
  {
    $group: {
      _id: "$customerId",
      revenue: { $sum: { $multiply: ["$items.quantity", "$items.unitPrice"] } }
    }
  },
  { $sort: { revenue: -1 } }
])

Le pipeline est puissant, mais l'ordre des étapes affecte le sens et les ressources consommées. De grands tableaux peuvent multiplier le jeu de travail après $unwind. Filtrer et projeter tôt peut réduire ce coût.

$lookup de MongoDB joint des documents d'une autre collection. C'est utile pour certaines relations, surtout si le côté joint est indexé et que le résultat reste petit. Un modèle qui nécessite plusieurs étapes $lookup pour des requêtes courantes indique que ses frontières sont peut-être relationnelles.

PostgreSQL est généralement plus simple pour la business intelligence, les rapports financiers, l'analyse de cohortes et les questions non planifiées, car la plupart des outils de reporting parlent SQL. Le reporting MongoDB fonctionne bien lorsque les dimensions résident déjà ensemble ou qu'un modèle de lecture préparé correspond au rapport. Les équipes qui font souvent des analyses ponctuelles exportent fréquemment les données opérationnelles vers un entrepôt, quelle que soit la base principale.

Le mapping objet ne supprime pas ces compromis. Un ORM peut faire ressembler des lignes PostgreSQL à des objets, tandis qu'un mapper objet-document peut imposer des classes aux documents MongoDB. Les relations stockées, les index et les règles d'intégrité déterminent toujours le comportement sous charge.

Transactions et concurrence

PostgreSQL offre le modèle le plus naturel pour les transactions sur plusieurs lignes et tables, tandis que MongoDB propose la frontière atomique la moins coûteuse pour les modifications d'un seul document et prend en charge des transactions plus larges si nécessaire. Le bon choix dépend des invariants qui doivent survivre aux requêtes concurrentes.

PostgreSQL utilise le contrôle de concurrence multiversion. Les lectures et écritures ordinaires peuvent avancer en parallèle, même si les verrous de ligne, verrous explicites, transactions longues et changements de schéma peuvent toujours créer des attentes. Read Committed est le niveau d'isolation par défaut. Repeatable Read fournit un instantané stable de transaction, et Serializable détecte les exécutions qui ne peuvent pas être ordonnées sans risque.

Les opérations MongoDB qui modifient un document sont atomiques. Intégrer un agrégat borné réduit donc la coordination. MongoDB prend aussi en charge les transactions ACID multi-documents dans les jeux de réplicas et les clusters partitionnés. Ces transactions ajoutent de la coordination, conservent des ressources pendant leur durée et peuvent produire des échecs transitoires qui imposent à l'application de rejouer toute la transaction.

MongoDB expose séparément le niveau de lecture, le niveau d'écriture et la préférence de lecture. Ces réglages déterminent quelles données une lecture peut observer, combien de membres du jeu de réplicas doivent confirmer une écriture et si les lectures peuvent aller vers des secondaires. Considérez-les d'abord comme des réglages de cohérence avant de les traiter comme des contrôles de latence.

Aucune base ne peut inclure un prestataire de paiement externe dans une transaction locale. Garder une transaction ouverte pendant une requête réseau augmente la contention sans pouvoir rendre les deux systèmes atomiques. Un flux de paiement plus sûr enregistre une commande en attente et un événement de boîte d'envoi dans une transaction de base, traite la requête externe de façon idempotente, puis enregistre le résultat.

Les tests de concurrence doivent cibler les courses métier, pas seulement les requêtes réussies. Par exemple, deux acheteurs qui réservent le dernier article, deux workers qui réclament la même tâche ou deux administrateurs qui attribuent le même nom unique. PostgreSQL peut souvent exprimer ces opérations avec des contraintes, des verrous de ligne ou des instructions atomiques. MongoDB peut utiliser des mises à jour conditionnelles, des index uniques et des transactions.

Si des règles strictes couvrent de nombreux enregistrements stockés indépendamment, PostgreSQL exige généralement moins de coordination applicative. Si chaque règle tient dans un document bien conçu, les opérations atomiques sur documents de MongoDB restent simples et efficaces.

PostgreSQL JSONB, une voie intermédiaire

PostgreSQL JSONB est une option solide lorsque des champs relationnels stables entourent un ensemble limité d'attributs évolutifs. Il ne transforme pas tous les problèmes de type document en problèmes relationnels, mais peut éviter d'ajouter une seconde base de données.

Un modèle courant place l'identité, la propriété, l'état et les horodatages dans des colonnes typées, tandis que les attributs optionnels vont dans jsonb. Les clés étrangères protègent les relations, les index ordinaires soutiennent les filtres fréquents et les index GIN ou d'expression accélèrent certains prédicats JSON.

CREATE TABLE products (
    id bigint PRIMARY KEY,
    account_id bigint NOT NULL REFERENCES accounts(id),
    sku text NOT NULL,
    status text NOT NULL,
    attributes jsonb NOT NULL DEFAULT '{}'::jsonb,
    UNIQUE (account_id, sku)
);

CREATE INDEX products_attributes_gin
    ON products USING gin (attributes);

Cette approche convient aux attributs de catalogue comme le matériau, les dimensions ou les métadonnées régionales qui diffèrent selon les types de produits. Elle convient moins lorsque chaque champ important est enfoui dans du JSON et que chaque requête exige des conversions, expressions de chemin ou validations personnalisées.

JSONB stocke une représentation binaire analysée, prend en charge les opérateurs de contenance et élimine le formatage non significatif comme l'ordre des propriétés d'objet. Il ne conserve aussi qu'une valeur pour une propriété d'objet dupliquée. Les applications qui doivent reproduire exactement le texte JSON d'origine doivent conserver ce texte séparément.

Mettre à jour une petite propriété crée une nouvelle version de ligne PostgreSQL et peut réécrire une valeur JSONB importante. De grands documents fréquemment mis à jour peuvent donc générer beaucoup de journalisation anticipée et de tuples morts. Répartir les champs actifs entre colonnes ou tables enfants fonctionne souvent mieux.

Les clés étrangères ne peuvent pas imposer directement des relations cachées dans un JSON arbitraire. Faites passer en colonnes les valeurs fréquemment interrogées, jointes, triées ou soumises à des contraintes. Les colonnes générées et index d'expression peuvent aider lors d'une transition progressive, mais un champ relationnel est généralement plus clair une fois son sens stabilisé.

Indexation et plans de requête

Les deux bases dépendent d'index adaptés aux vrais filtres, tris et cardinalités. Une indexation indiscriminée ralentit les écritures et consomme de la mémoire. Les moteurs offrent des outils d'indexation différents, mais aucun ne peut sauver un mode d'accès qui contredit le modèle stocké.

PostgreSQL utilise des index B-tree pour l'égalité, les plages et les récupérations ordonnées. Les index GIN prennent en charge la contenance JSONB, les tableaux et la recherche plein texte. GiST et SP-GiST couvrent plusieurs classes d'opérateurs géométriques, de plage et spécialisés. Les index BRIN sont compacts pour les très grandes tables dont l'ordre physique est corrélé à une valeur, comme le temps.

PostgreSQL prend aussi en charge les index partiels et d'expression. Un index partiel sur les abonnements actifs peut être bien plus petit qu'un index couvrant des années d'enregistrements inactifs. Un index d'expression peut servir une adresse e-mail normalisée ou une propriété JSON précise.

MongoDB indexe directement les propriétés imbriquées et les tableaux. Un index multikey développe les valeurs de tableau en entrées d'index, ce qui rend les requêtes d'appartenance efficaces mais peut rapidement grossir l'index. Un index multikey composé ne peut pas indexer plus d'un champ de type tableau dans le même document. MongoDB fournit aussi des options d'index géospatial, haché, wildcard, partiel, sparse et TTL pour les modes d'accès correspondants.

L'ordre des colonnes dans les index composés suit la structure des requêtes, pas une règle universelle consistant à placer d'abord la colonne la plus sélective. Dans un B-tree multicolonne PostgreSQL, des conditions d'égalité sur les premières colonnes suivies d'une plage sur la colonne suivante permettent souvent un parcours efficace. Les utilisateurs de MongoDB commencent souvent par les champs d'égalité, puis de tri, puis de plage, tout en vérifiant si un autre ordre examine moins d'entrées pour la distribution réelle.

Utilisez les plans de requête plutôt que des hypothèses :

• Dans PostgreSQL, lancez EXPLAIN (ANALYZE, BUFFERS) sur des lectures représentatives et examinez les estimations de lignes, boucles, tris, écritures disque et activité des buffers.
• N'oubliez pas que ANALYZE exécute l'instruction : soyez prudent avec les écritures et le trafic de production.
• Dans MongoDB, demandez des statistiques d'exécution et comparez les documents examinés, entrées d'index examinées et résultats renvoyés.
• Testez les valeurs de paramètres courantes ainsi que les valeurs asymétriques correspondant à une grande part des données.
• Ne supprimez les index inutilisés qu'après avoir confirmé leur absence des charges périodiques, administratives et de basculement.

Un index qui couvre parfaitement un endpoint peut dupliquer un autre index ou alourdir chaque écriture. Examinez l'ensemble complet des index comme un portefeuille plutôt que d'approuver chacun isolément.

Recherche, géospatial et séries temporelles

Les deux bases couvrent la recherche élémentaire, la localisation et les requêtes temporelles, mais des exigences produit spécialisées peuvent justifier des outils distincts ou des fonctions managées. Le choix doit dépendre de la qualité de pertinence, du débit d'ingestion, de la rétention et de la responsabilité opérationnelle.

La recherche plein texte PostgreSQL fournit segmentation, dictionnaires, vecteurs de documents pondérés, opérateurs de requête, classement et accélération GIN. Elle fonctionne bien pour la recherche au sein d'une application lorsque le corpus et les règles de pertinence restent gérables. Les index trigrammes peuvent prendre en charge la similarité et la recherche de sous-chaînes pour les noms ou identifiants.

Les index de texte MongoDB gèrent la recherche par mots de base. La plateforme managée de MongoDB propose aussi des capacités séparées de recherche et de recherche vectorielle, conçues pour des charges de pertinence et de récupération plus riches. Traitez-les comme des services propres au déploiement lorsque vous comparez portabilité, prix, comportement des sauvegardes et développement local.

La recherche vectorielle change le type de requête, sans supprimer le besoin d'une source transactionnelle de vérité. PostgreSQL peut ajouter une indexation vectorielle via des extensions, tandis que les déploiements MongoDB peuvent associer les documents opérationnels à des services de recherche vectorielle pris en charge. Évaluez le rappel, le filtrage, le temps de construction de l'index, la visibilité des mises à jour et le coût avec les embeddings de l'application.

Pour le géospatial, PostgreSQL utilise couramment l'extension PostGIS pour la géométrie avancée, les systèmes de coordonnées et l'analyse spatiale. MongoDB fournit des index et opérateurs géospatiaux adaptés aux requêtes d'applications sensibles à la localisation. Ne retenez l'option la plus simple qu'après avoir listé les opérations réelles : trouver des points proches est bien moins exigeant que réparer des polygones ou réaliser des jointures spatiales complexes.

Les collections de séries temporelles MongoDB organisent les mesures dans des buckets internes et prennent en charge l'expiration par le temps. PostgreSQL gère les données temporelles avec le partitionnement, les index BRIN et des extensions facultatives. Une télémétrie à très haut volume peut tout de même trouver sa place dans un stockage analytique spécialisé après ingestion, surtout lorsque la rétention longue et les analyses étendues comptent plus que les mises à jour transactionnelles.

Performances et benchmarks représentatifs

La disposition des données, la couverture des index, la taille du jeu de travail et les réglages de durabilité comptent généralement davantage que les résultats génériques de benchmarks MongoDB contre PostgreSQL. Un test crédible reproduit la distribution de données et la concurrence de l'application.

MongoDB peut produire des lectures à faible latence lorsqu'une requête correspond à un document indexé. Cet avantage se réduit lorsque les documents sont volumineux, que les réponses n'ont besoin que de quelques champs dispersés ou que les relations exigent des recherches répétées. Les tableaux intégrés augmentent aussi le nombre d'entrées d'index et peuvent rendre les mises à jour de plus en plus coûteuses.

PostgreSQL peut exécuter efficacement des jointures complexes lorsque les statistiques sont exactes et les colonnes de jointure indexées. Les performances se dégradent lorsqu'une requête crée un gros résultat intermédiaire, déverse des tris ou tables de hachage sur disque, ou récupère à répétition de nombreuses pages sans rapport. Sélectionner uniquement les colonnes nécessaires et corriger les erreurs de modèle comptent souvent davantage que réécrire la syntaxe SQL.

Chaque index secondaire augmente le travail d'écriture dans les deux systèmes. Les grandes valeurs JSONB, lignes larges, documents surdimensionnés et données dénormalisées dupliquées augmentent les entrées-sorties. Les tempêtes de connexions peuvent épuiser les ressources même si chaque requête est rapide : utilisez donc des pools limités et testez le comportement de reconnexion lors d'un basculement.

Un benchmark utile doit préserver ces conditions :

• Chargez assez de données pour représenter le rapport attendu entre le jeu de travail et la mémoire disponible.
• Reproduisez les réglages de cohérence, journalisation, réplication et acquittement de production.
• Rejouez les principales opérations de l'application avec des proportions réalistes de lectures et écritures.
• Incluez l'asymétrie, les clients très actifs, les gros comptes, les enregistrements absents et les filtres les plus défavorables.
• Enregistrez le débit ainsi que les latences p50, p95 et p99 pendant une charge stable et des événements de reprise.

N'effectuez qu'un changement contrôlé à la fois. Comparez des tables normalisées avec JSONB, des documents intégrés avec des références ou différents index, tout en gardant constants le matériel et la sémantique des requêtes. Les microbenchmarks avec cache chaud ne peuvent pas prévoir la pression des sauvegardes, le retard de réplication, le comportement des checkpoints ni les performances après la perte d'un primaire.

La planification de capacité doit inclure la croissance des données et des index. Un index qui tient en mémoire au lancement peut dominer la latence après un an. Répétez les tests avec le volume de données prévu plutôt que d'extrapoler depuis une base vide.

Mise à l'échelle horizontale et distribution des données

MongoDB propose un partitionnement intégré pour distribuer les écritures, tandis que PostgreSQL combine généralement montée en puissance verticale, partitionnement et réplicas avant d'adopter une architecture distribuée distincte. La mise à l'échelle horizontale introduit des décisions de routage et de propriété qui affectent chaque requête.

Un cluster MongoDB partitionné distribue les documents selon une clé de partitionnement. Une bonne clé a une cardinalité suffisante, évite de concentrer progressivement les écritures, prend en charge les prédicats de routage courants et répartit uniformément le stockage. Une requête qui omet la clé de partitionnement peut contacter tous les shards, augmentant la latence et les ressources consommées.

Le partitionnement haché peut mieux répartir les identifiants séquentiels, mais réduit la localité des plages. Le partitionnement par plage permet de cibler des intervalles, mais peut créer une extrémité de plage très sollicitée. Les zones peuvent placer des plages choisies sur des shards désignés pour des règles de client ou géographiques. Le repartitionnement peut corriger un mauvais choix, mais déplacer un grand jeu de données actif exige toujours une planification et de la capacité disponible.

Les transactions MongoDB peuvent couvrir plusieurs shards, mais la coordination entre shards coûte plus cher que les opérations routées vers un seul shard. Les applications qui incluent l'identifiant du client dans la clé de partitionnement et les requêtes courantes peuvent souvent garder le travail associé local.

Le partitionnement natif PostgreSQL divise une table logique en tables enfants, généralement par temps, client ou autre valeur de routage. L'élagage des partitions réduit les parcours et les partitions simplifient les opérations de rétention. Le partitionnement natif seul ne distribue pas les écritures entre machines : il ne faut donc pas le présenter comme du sharding.

Les réplicas de lecture PostgreSQL peuvent éloigner du primaire un trafic de lecture adapté. Ils n'augmentent pas la capacité d'écriture du primaire et les réplicas asynchrones peuvent renvoyer des données plus anciennes. Les applications doivent déterminer quelles lectures tolèrent ce délai.

Lorsqu'un seul writer PostgreSQL ne suffit plus, les équipes peuvent partitionner dans le code applicatif, adopter une extension ou un service PostgreSQL distribué, ou séparer les domaines dans des bases indépendantes. Chaque option modifie le comportement des jointures inter-shards, de l'unicité, des séquences et des transactions. Testez ces limites avant que l'application ne dépende d'opérations globales.

Exprimez les besoins de mise à l'échelle en chiffres. Les écritures attendues par seconde, la taille du jeu de données, la concentration des clients actifs, le placement régional et les objectifs de reprise sont plus utiles qu'une exigence générale de mise à l'échelle horizontale.

Réplication, basculement et reprise

Les deux bases peuvent fournir une haute disponibilité, mais le comportement de reprise dépend de la topologie, de la politique d'acquittement, de l'automatisation et de tests répétés. La réplication seule ne garantit ni une courte indisponibilité ni l'absence de perte de données.

MongoDB fonctionne couramment sous forme de jeu de réplicas avec un primaire et plusieurs secondaires. Les membres élisent un nouveau primaire lorsque le primaire actuel devient indisponible. Les applications doivent utiliser des pilotes pris en charge, configurer des délais de sélection de serveur et d'opération, puis gérer les erreurs transitoires. Les écritures rejouables aident certaines opérations, mais les reprises doivent toujours respecter l'idempotence de l'application.

Le niveau d'écriture contrôle combien de membres acquittent une écriture. La préférence de lecture détermine si les lectures éligibles utilisent le primaire ou des secondaires, et le niveau de lecture contrôle les garanties de visibilité. Une configuration à faible latence peut exposer davantage de risques d'échec ou de données obsolètes : documentez donc la combinaison choisie pour chaque charge.

La réplication physique en flux PostgreSQL envoie les journaux de transactions du primaire vers les standby. La réplication asynchrone protège la disponibilité et la latence, mais peut perdre des transactions récemment acquittées si le primaire est détruit avant qu'un standby ne les reçoive. La réplication synchrone peut réduire cette exposition tout en augmentant la latence de validation et la sensibilité à l'état des standby.

Le basculement PostgreSQL est normalement coordonné par un service managé ou une automatisation externe. La procédure doit promouvoir un standby approprié, rediriger les clients et empêcher l'ancien primaire d'accepter des écritures conflictuelles. Les pools de connexions et caches DNS peuvent prolonger l'interruption visible après la promotion.

Les sauvegardes protègent contre les défaillances que la réplication copie fidèlement, notamment les suppressions accidentelles et la corruption logique. Les sauvegardes de base PostgreSQL accompagnées de journaux archivés permettent une récupération à un instant donné. Les déploiements MongoDB peuvent utiliser des snapshots coordonnés et une récupération basée sur l'oplog via les outils ou services managés adaptés.

Définissez séparément l'objectif de point de reprise et l'objectif de temps de reprise. Testez ensuite une restauration complète dans un environnement isolé, vérifiez les données applicatives, renouvelez les identifiants restaurés et consignez le temps écoulé. Un snapshot réussi ne prouve pas qu'un service complet peut être restauré dans le délai fixé.

Maintenance opérationnelle

PostgreSQL et MongoDB exigent des maintenances courantes différentes : l'expérience de l'équipe peut donc peser plus que de petits écarts de fonctionnalités. Les services managés réduisent une partie du travail, mais ne prennent pas en charge la conception des requêtes, les décisions de capacité ou la vérification des restaurations.

PostgreSQL crée des versions de lignes obsolètes lorsque les transactions mettent à jour ou suppriment des données. Autovacuum récupère l'espace réutilisable, met à jour les informations de visibilité et empêche l'épuisement des identifiants de transaction. Les transactions longues peuvent retarder le nettoyage. Surveillez les tuples morts, la croissance des tables et index, la progression du vacuum, l'âge des transactions et les requêtes qui maintiennent d'anciens instantanés actifs.

Les statistiques du planificateur demandent aussi de l'attention. Des valeurs asymétriques ou colonnes corrélées peuvent produire de mauvaises estimations et de mauvais plans. Augmenter les cibles statistiques ou créer des statistiques étendues peut aider certaines requêtes. Examinez les performances après une forte croissance des données, pas seulement après des changements de code.

Le moteur de stockage WiredTiger de MongoDB dépend fortement de son cache et de sa compression. Surveillez la pression sur le cache, la latence disque, la croissance des documents, le comportement des checkpoints, le retard de réplication et le rapport entre documents examinés et renvoyés. Dans les déploiements partitionnés, surveillez le rééquilibrage, la distribution inégale des chunks et les opérations qui dispersent les requêtes entre shards.

Les procédures courantes doivent couvrir cinq domaines :

• La capture des requêtes lentes, leur responsabilité et les seuils de correction.
• Les alertes de capacité fondées sur le taux de croissance, pas seulement sur le remplissage actuel.
• Les exercices de restauration avec temps de reprise et étapes de validation consignés.
• La rotation des identifiants et les procédures d'accès d'urgence.
• Les mises à niveau de version testées avec les pilotes, extensions, index et plans de retour en arrière.

Les mises à niveau majeures de PostgreSQL utilisent couramment pg_upgrade, la réplication logique ou un processus de migration managé. La compatibilité des extensions peut déterminer le chemin possible. Les mises à niveau MongoDB suivent des séquences de versions prises en charge et les contrôles de Feature Compatibility Version ; les clusters partitionnés exigent un ordre précis des composants.

Les outils d'export logique comme pg_dump et mongodump sont pratiques pour les petits jeux de données et les restaurations ciblées. Ils peuvent être trop lents pour des objectifs de reprise stricts à grande échelle. Mesurez la durée d'export et d'import avec des données de taille production avant d'en faire la principale méthode de reprise après sinistre.

Sécurité et gouvernance

Les deux bases peuvent satisfaire à des exigences de sécurité élevées si les accès, le chiffrement, l'audit et les contrôles réseau sont conçus explicitement. Des identifiants par défaut ou un réseau privé ne suffisent pas à créer un système auditable.

Les rôles PostgreSQL peuvent recevoir des privilèges aux niveaux de la base, du schéma, de la table, de la séquence, de la fonction et de la colonne. Les vues peuvent exposer des champs choisis, et la sécurité au niveau des lignes peut restreindre les lignes selon le contexte utilisateur ou client. Séparez la propriété des objets des rôles applicatifs habituels afin qu'un service compromis ne puisse pas modifier ses propres restrictions.

Les rôles MongoDB accordent des actions sur les bases, collections et ressources du cluster. Utilisez des identités séparées pour les lectures applicatives, écritures applicatives, migrations, supervision, sauvegardes et administration. Évitez de partager un même identifiant doté de privilèges étendus entre services.

Un ensemble de contrôles pratique comprend :

• Exigez TLS pour le trafic client et de réplication, puis vérifiez la gestion des certificats dans chaque pilote.
• Stockez les secrets dans un système de gestion de secrets managé et renouvelez-les sans publier toute l'application.
• Limitez les routes réseau et évitez d'exposer directement les écouteurs de base de données sur Internet.
• Enregistrez les événements d'authentification, privilèges, schéma et accès aux données sensibles imposés par la politique.
• Vérifiez que les analystes, équipes support et comptes d'automatisation ne dépassent pas leurs responsabilités attribuées.

Le chiffrement au repos peut associer les capacités de la base, le stockage chiffré et des clés gérées dans le cloud. MongoDB prend aussi en charge le chiffrement de champs côté client dans les déploiements pris en charge. Les applications PostgreSQL chiffrent couramment certaines valeurs avant stockage lorsque les administrateurs de base ne doivent pas voir le texte en clair. Le chiffrement modifie les possibilités d'indexation et de requête : prototypez d'abord les opérations protégées.

La gouvernance exige aussi des procédures de classification, conservation, suppression, résidence des données et réponse aux incidents. Le placement régional peut aider à atteindre des objectifs de résidence, mais la conformité dépend des sauvegardes, journaux, accès du support, sous-traitants et de tout système qui reçoit les données.

Coût, licences et coût total de possession

La base la moins chère est celle qui répond à la charge avec une infrastructure, des frais de service et un effort d'ingénierie acceptables. Le prix de licence détermine rarement à lui seul le coût total de possession.

Le coût du calcul augmente avec les requêtes complexes, le travail de compression, la maintenance des index, les tâches d'arrière-plan et la réplication. Le stockage inclut les index, journaux conservés, sauvegardes, espace temporaire et données dupliquées par dénormalisation. Trois réplicas contenant des données stockent plusieurs copies avant même de compter les snapshots et transferts interrégionaux.

PostgreSQL utilise la licence permissive PostgreSQL et est disponible dans de nombreuses distributions auto-hébergées et managées. Le support commercial et les services cloud sont facultatifs. Les extensions peuvent avoir leurs propres licences : examinez-les séparément.

MongoDB Community Server utilise la Server Side Public License, disponible en source mais non approuvée par l'Open Source Initiative. MongoDB Atlas et le support commercial appliquent les tarifs et conditions du fournisseur. Les organisations qui intègrent ou proposent une fonctionnalité de base de données en tant que service doivent faire examiner les conditions applicables par leur conseil juridique plutôt que de supposer qu'elles correspondent à une licence open source permissive.

Les bases managées échangent un prix unitaire supérieur contre le provisionnement automatisé, les correctifs, sauvegardes, intégrations de supervision et une partie du processus de basculement. Elles laissent toutefois au client la qualité du schéma, les requêtes lentes, la gestion des connexions, la classification des données et la reprise applicative.

Estimez le coût total avec ces éléments :

• Le nombre d'environnements de production, préproduction, développement, reprise après sinistre et temporaires.
• La croissance des données et index sur au moins les 12 à 24 prochains mois.
• Les réplicas, régions, rétention des sauvegardes et transferts réseau nécessaires.
• Le débit de pointe, la mémoire du jeu de travail et les performances de stockage provisionnées.
• Le temps du personnel consacré aux migrations, réglages, réponses aux incidents, audits et exercices de restauration.

Une base déjà bien maîtrisée par l'équipe peut coûter moins cher qu'une alternative techniquement séduisante. La formation, la nouvelle automatisation, la révision des procédures d'astreinte et le risque de migration sont des coûts réels.

Adéquation à l'application selon la charge de travail

PostgreSQL est le meilleur choix par défaut pour les systèmes de référence riches en relations, tandis que MongoDB trouve sa place dans les domaines composés de documents variables détenus indépendamment. Les flux spécifiques révèlent mieux l'adéquation que de grandes étiquettes comme application web ou système d'entreprise.

Un modèle de compte SaaS comprend généralement des organisations, adhésions, invitations, rôles, abonnements, factures, droits et journaux d'audit. L'unicité et les règles entre entités sont centrales, et les administrateurs finissent par demander des rapports qui n'étaient pas prévus au lancement. PostgreSQL convient très bien à ce modèle.

Un catalogue produit peut contenir des ensembles d'attributs différents pour les vêtements, l'électronique, les pièces industrielles et les catégories personnalisées par client. MongoDB peut stocker chaque produit comme un document cohérent sans créer une table universelle clairsemée. PostgreSQL avec JSONB reste compétitif lorsque les produits participent aussi beaucoup à des tables de prix, transactions de stock, accords fournisseurs et rapports relationnels.

Un domaine de gestion de contenu s'adapte souvent naturellement à des documents contenant blocs, localisation, métadonnées et état de publication. MongoDB fonctionne bien lorsque chaque entrée est lue et révisée comme une unité. PostgreSQL peut être préférable lorsque les permissions éditoriales, la planification, les références entre contenus et le reporting sont plus exigeants que la variation des documents.

Les grands livres financiers, réservations de stock et enregistrements de facturation favorisent PostgreSQL. Une conception en ajout seul ne supprime pas le besoin d'unicité, d'écritures équilibrées, de requêtes de rapprochement et d'invariants portant sur plusieurs enregistrements.

Les systèmes d'événements et de télémétrie exigent un test plus détaillé. MongoDB peut ingérer des événements sous forme de documents, et PostgreSQL peut partitionner des tables fortement alimentées en ajouts. À une échelle analytique soutenue, la base opérationnelle peut alimenter un entrepôt en colonnes ou un système de séries temporelles dédié. La rétention, les fenêtres d'agrégation, les arrivées tardives et la taille des parcours de requête doivent décider du chemin de stockage.

Une architecture hybride se justifie lorsque les entités de référence restent dans PostgreSQL et qu'un domaine documentaire a une propriété et des modes d'accès distincts. Attribuez une source de vérité par entité. Publiez les changements via une boîte d'envoi ou un processus de capture des changements, utilisez des consommateurs idempotents et prévoyez des livraisons retardées ou répétées. Évitez les doubles écritures synchrones, qui peuvent laisser les stockages incohérents après un échec partiel.

Une méthode de décision pratique

Une courte preuve de concept avec des données proches de la production est la façon la plus fiable de trancher entre MongoDB et PostgreSQL lorsque le choix est serré. Le test doit se concentrer sur les points difficiles plutôt que sur une démonstration générique de création, lecture, mise à jour et suppression.

Sélectionnez trois flux représentatifs : la requête la plus courante, la requête la plus complexe et l'opération avec l'exigence de correction la plus stricte. Modélisez honnêtement chaque flux dans les deux bases. Ne forcez pas PostgreSQL à imiter un magasin de documents avec une seule colonne JSON sans restriction, et ne forcez pas MongoDB à reproduire un schéma très normalisé dans de nombreuses collections.

Évaluez chaque candidat selon la clarté du modèle, la correction, l'effort de requête, la latence mesurée, la familiarité opérationnelle, la reprise, les contrôles de sécurité et le coût projeté. Pondérez les catégories avant de voir les résultats des benchmarks. Une application financière doit accorder plus de poids à l'intégrité et à l'auditabilité qu'à l'évitement des migrations, tandis qu'un prototype de contenu jetable peut faire l'inverse.

Rejetez un modèle s'il dépend de l'une de ces hypothèses :

• Chaque requête future suivra le modèle d'accès de la première API.
• La validation applicative s'exécutera correctement pour chaque chemin d'écriture, indéfiniment.
• Un gros client se comportera comme le client médian.
• La réplication supprime le besoin de sauvegardes et d'exercices de restauration.
• Une seconde base entraîne peu de coût opérationnel parce que son premier déploiement est managé.

Pour une application transactionnelle générale, PostgreSQL reste le point de départ le plus sûr. Ses tables, SQL, contraintes, modèle de transaction mature et prise en charge de JSONB laissent de la place aux données structurées comme à certaines données semi-structurées. MongoDB doit l'emporter parce que son modèle documentaire produit une conception réellement plus simple ou parce que son modèle de distribution intégré répond à des besoins mesurés, pas parce que les migrations semblent contraignantes.

Appliquer ce choix aux projets Koder.ai

PostgreSQL est le point de départ naturel pour la plupart des projets Koder.ai, car la pile principale de la plateforme utilise React, Go, PostgreSQL et Flutter pour les applications mobiles. Ce choix par défaut convient aux sites web, CRM, ERP, applications mobiles et autres systèmes transactionnels couramment créés via son interface de chat.

Le mode Planification doit identifier les entités, relations, règles d'unicité, conservation des données et opérations à fort volume avant le début de la génération. Les propriétés stables doivent aller dans des colonnes typées. Les attributs métier optionnels peuvent utiliser JSONB lorsque leur structure varie réellement.

Koder.ai prend en charge l'export du code source, le déploiement et l'hébergement, les domaines personnalisés, les instantanés et le retour en arrière. Les instantanés et le retour arrière de l'application doivent compléter la planification des migrations de base, sans la remplacer. Revenir au code applicatif après un changement de schéma incompatible peut laisser l'ancien code incapable de lire les données nouvellement écrites.

Pour les services Go générés, conservez les changements de base dans des migrations revues et rendez les déploiements sûrs pendant la période de transition. Une séquence courante consiste à ajouter un schéma compatible, déployer du code qui comprend les deux états, compléter les données, basculer les lectures, puis supprimer l'ancienne forme dans une version ultérieure.

Koder.ai peut exécuter des applications sur une infrastructure AWS dans différents pays afin de répondre aux exigences de placement des données. La conception de la base doit étendre cette décision aux réplicas, sauvegardes, journaux, exports analytiques et accès administratifs. Le placement géographique n'est qu'un contrôle parmi d'autres dans un plan plus large de confidentialité et gouvernance.

Ajouter MongoDB à un projet reposant sur PostgreSQL doit respecter le même niveau d'exigence que toute dépendance d'architecture : définissez le domaine détenu par les documents, la gestion des défaillances, le chemin de synchronisation, la politique de sauvegarde et la responsabilité d'exploitation avant l'implémentation.

Checklist de migration et d'adoption

Une migration de base de données réussit lorsque l'équipe peut prouver l'exhaustivité des données, la compatibilité de l'application et un basculement récupérable. Convertir la syntaxe ne constitue qu'une partie du travail.

Commencez par inventorier les tables ou collections, le volume de données, les index, contraintes, modes de requête, règles de conservation et tous les writers. Identifiez les sémantiques qui ne se traduisent pas directement, comme des clés étrangères relationnelles devenant des références, des tableaux intégrés devenant des tables enfants, des différences de précision numérique, des comparaisons sensibles à la casse ou la gestion des horodatages.

Construisez des requêtes de rapprochement avant de déplacer les données de production. Les seuls comptages ne suffisent pas. Comparez les totaux par client et par date, vérifiez l'unicité, échantillonnez les gros enregistrements, contrôlez les relations orphelines et calculez les soldes métier lorsque c'est utile.

Une migration contrôlée comprend normalement ces étapes :

• Effectuez une première copie en masse et consignez les enregistrements rejetés ou transformés.
• Capturez les changements suivants grâce à un journal, une boîte d'envoi ou un mécanisme de capture des changements.
• Exécutez des lectures fantômes ou comparez des réponses échantillonnées sans modifier le comportement visible pour les utilisateurs.
• Basculez via un changement de routage réversible tout en surveillant les erreurs et le retard.
• Gardez l'ancien stockage en lecture seule jusqu'à la fin du rapprochement et de la fenêtre de retour en arrière.

La double écriture depuis le code applicatif est risquée sauf si les deux écritures sont idempotentes et les échecs partiels réconciliés explicitement. Préférez une source validée avec un enregistrement de livraison asynchrone qui peut être rejoué.

Après le basculement, reconstruisez les références opérationnelles. Les plans de requête, tailles de pools de connexions, seuils d'alerte, durée des sauvegardes et prévisions de capacité de l'ancien moteur ne se transfèrent pas automatiquement. La migration est terminée seulement après un exercice de restauration réussi dans la nouvelle base et lorsque l'équipe sait l'exploiter durant une défaillance.