PostgreSQL vs MongoDB en 2026 : comment choisir, avec des exemples concrets

Le vrai problème n'est pas la base de données, c'est la mauvaise question

Chaque année, au moins un client arrive avec la même histoire. Ils ont choisi MongoDB parce que c'est « plus flexible », ou PostgreSQL parce que « c'est ce qu'on connaissait ». Six mois plus tard, ils réécrivent des requêtes d'agrégation de zéro ou tentent d'imposer un schéma rigide sur une collection devenue un champ de mines de champs optionnels.

En 2026, les deux bases de données sont matures, scalables et soutenues par des écosystèmes solides. Un mauvais choix ne vous tue pas — mais il vous coûte. En temps de développement, en complexité opérationnelle, en dette technique.

Alors : comment décider ?

---

Les différences qui comptent vraiment

Modèle de données

PostgreSQL est relationnel. Les données ont un schéma déclaré, les relations sont explicites, les contraintes d'intégrité sont appliquées par le moteur. Ce n'est pas une limitation : c'est une garantie.

MongoDB est orienté document. Chaque document est un JSON arbitraire. Il n'existe pas de schéma obligatoire au niveau du moteur (bien que la validation JSON Schema optionnelle soit disponible depuis 2019). La flexibilité est réelle, mais elle a un prix : la cohérence des données devient la responsabilité de l'application.

Patterns d'accès

La question à se poser est : comment vos requêtes vont-elles lire les données ?

Relations complexes many-to-many ? Jointures multiples, agrégations sur des tables différentes ? → PostgreSQL.
Vos données sont hiérarchiques et lues/écrites ensemble comme une unité ? → MongoDB.
Vous avez besoin de transactions ACID multi-entités ? → PostgreSQL (MongoDB supporte les transactions multi-documents depuis la 4.0, mais avec un overhead non négligeable).
Votre schéma évolue fréquemment pour des raisons produit, pas des bugs ? → MongoDB mérite d'être envisagé.

Exemple concret : e-commerce

Imaginez un catalogue produits avec variantes, attributs dynamiques par catégorie (chaussures → taille/couleur, électronique → tension/fréquence) et prix par marché.

Avec PostgreSQL :

CREATE TABLE products (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  category_id INT REFERENCES categories(id)
);

CREATE TABLE product_attributes (
  product_id UUID REFERENCES products(id),
  key TEXT NOT NULL,
  value TEXT NOT NULL,
  PRIMARY KEY (product_id, key)
);

Cela fonctionne, mais les requêtes pour récupérer un produit avec tous ses attributs deviennent des jointures et des pivots. Pas impossible, mais verbeux.

Alternativement, PostgreSQL supporte JSONB :

CREATE TABLE products (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  category TEXT NOT NULL,
  attributes JSONB
);

-- Index sur un champ JSON imbriqué
CREATE INDEX idx_products_color
  ON products ((attributes->>'color'));

-- Requête
SELECT name, attributes->>'color' AS color
FROM products
WHERE category = 'shoes'
  AND attributes->>'size' = '42';

JSONB dans PostgreSQL couvre beaucoup des cas d'usage qui poussent vers MongoDB, sans abandonner le modèle relationnel pour le reste du système.

Avec MongoDB :

// Document produit
{
  _id: ObjectId("..."),
  name: "Sneaker X",
  category: "shoes",
  attributes: { color: "white", size: "42" },
  prices: [
    { market: "IT", amount: 89.99, currency: "EUR" },
    { market: "US", amount: 95.00, currency: "USD" }
  ]
}

// Requête
db.products.find(
  { category: "shoes", "attributes.size": "42" },
  { name: 1, "attributes.color": 1 }
);

La lecture est simple et le document est autonome. Mais si vous devez produire un rapport croisant produits, commandes et clients, vous allez découvrir $lookup — et c'est moins élégant qu'un JOIN déclaratif.

---

Quand PostgreSQL est la réponse évidente

Données financières ou transactionnelles. Les transactions ACID de PostgreSQL sont éprouvées. Mouvements comptables, commandes, paiements : pas de débat.
Reporting et analytics internes. Window functions, CTE récursives, GROUPING SETS : PostgreSQL est un moteur analytique sérieux sans outillage supplémentaire.
Équipes avec une expertise SQL établie. Le coût d'onboarding avec un ORM et des migrations de schéma est connu et maîtrisable.
Systèmes avec des relations complexes entre entités. Utilisateurs, rôles, permissions, organisations, assets : le modèle relationnel rend ces contraintes explicites et vérifiables.

Quand MongoDB a du sens

Données hiérarchiques à structure variable. CMS, catalogues aux attributs très hétérogènes, configurations de tenants différant par leur forme.
Ingestion rapide de données semi-structurées. Logs applicatifs, événements IoT, flux tiers avec des schémas non maîtrisés.
Prototypes où le schéma évolue à chaque sprint. MongoDB permet d'itérer sans migration, mais cette liberté doit être disciplinée avant la mise en production.
Sharding horizontal natif. Pour des volumes très élevés avec des patterns d'accès bien définis, le sharding MongoDB est plus simple à configurer qu'avec les équivalents PostgreSQL (Citus, partitioning natif).

---

L'option hybride : pas un compromis, une architecture

Dans les systèmes complexes, utiliser les deux n'est pas de l'indécision. C'est un choix délibéré.

Un pattern courant dans les systèmes que nous accompagnons :

PostgreSQL pour le cœur transactionnel : utilisateurs, commandes, factures, ACL.
MongoDB pour les données à contexte variable : préférences utilisateur, payloads d'événements, historique d'activité aux schémas hétérogènes.
Redis pour le cache et le rate limiting.

L'essentiel est que la frontière entre les deux soit explicite dans le design et documentée. Le problème n'est pas d'utiliser deux bases de données — c'est de ne pas savoir pourquoi on les utilise toutes les deux.

---

Take-away opérationnel

Avant de choisir, répondez à ces questions :

Mes données ont-elles des relations fortes entre entités différentes ? → PostgreSQL.
Les documents sont-ils lus et écrits comme des unités autonomes, rarement en jointure ? → MongoDB.
Ai-je besoin de transactions ACID multi-entités ? → PostgreSQL (ou MongoDB 6+ avec attention aux coûts).
Mon schéma est-il instable pour des raisons produit légitimes ? → MongoDB, mais avec la validation JSON Schema activée.
JSONB dans PostgreSQL résout-il déjà le problème ? → N'ajoutez pas une seconde base de données par effet de mode.

La règle pratique : PostgreSQL est le choix par défaut sûr. MongoDB est le choix délibéré pour des cas spécifiques. Pas l'inverse.

---

Evviva Group accompagne les équipes de développement B2B dans le choix et la mise en place d'architectures de données. Si vous évaluez une migration ou une nouvelle architecture, nous pouvons vous aider à peser les trade-offs avant d'écrire la moindre ligne de code.