PostgreSQL vs MongoDB avec Laravel : comment choisir la bonne base de données

Quand je démarre un nouveau projet Laravel (une API, un micro-service, un SaaS ou même un simple site) la question de la base de données arrive très vite. Dois-je partir sur une base relationnelle solide, ou dois-je privilégier la souplesse d’un document-store NoSQL ?

Dans la pratique, deux options reviennent presque toujours : PostgreSQL et MongoDB. Ce sont deux technologies matures, largement utilisées, mais qui reposent sur des philosophies très différentes. Et comme souvent, derrière un choix technique se cachent des conséquences très concrètes pour le projet.

Voici donc mon analyse personnelle, basée sur mon expérience, pour comprendre dans quels cas l’une ou l’autre est le bon choix.

Deux philosophies, deux façons de penser la donnée

PostgreSQL : structure, rigueur et relations fortes

PostgreSQL appartient à la famille des SGBD relationnels. Les données y sont organisées en tables, avec un schéma clairement défini : colonnes, types, contraintes, clés étrangères… On conçoit la structure avant d’y insérer la moindre donnée.

Cette approche impose une certaine discipline, mais elle offre en retour :

• de la clarté,

• de la prévisibilité,

• et une modélisation robuste.

Pour des applications complexes (e-commerce, outils métier, SaaS, systèmes où les données sont liées) c’est un véritable atout. PostgreSQL apporte aussi la conformité ACID, l’isolation via MVCC, des index puissants (B-tree, GiST, GIN…), et la possibilité de requêtes SQL très avancées.

En clair : si ton application exige cohérence, relations, transactions fiables et requêtes complexes, PostgreSQL est un choix naturel.

MongoDB : flexibilité, rapidité d’évolution et données hétérogènes

MongoDB repose sur un paradigme totalement différent : celui des documents. Les données sont stockées sous forme de documents JSON/BSON, regroupés en collections. Aucun schéma strict n’est imposé : chaque document peut avoir ses propres champs et sa propre structure.

Cette liberté est l’un des plus grands avantages de MongoDB :

• tu peux itérer rapidement,

• faire évoluer ton modèle à mesure que le projet progresse,

• gérer facilement des données semi-structurées ou hétérogènes.

MongoDB excelle aussi en scalabilité horizontale (sharding, distribution sur plusieurs nœuds), ce qui en fait une solution pertinente pour les gros volumes de données ou les charges irrégulières.

Si ton application manipule des événements, des logs, des métadonnées, des documents dynamiques ou simplement un modèle de données encore flou, MongoDB peut s’avérer être un excellent choix.

PostgreSQL vs MongoDB : que choisir selon ton contexte Laravel ?

Voici comment je résume les forces de chacun dans une situation concrète.

Quand PostgreSQL est le bon choix ?

• Tu as des relations complexes (many-to-many, jointures, contraintes…).

• Tu as besoin de transactions ACID et d'une intégrité stricte.

• Tu utilises des requêtes SQL avancées, agrégations, filtres élaborés.

• Ton modèle de données est relativement stable.

• Tu veux de la maintenabilité, de la prévisibilité et un système facile à auditer.

En résumé : pour une application structurée, robuste, avec des règles métier claires, PostgreSQL s’impose.

Quand MongoDB a plus de sens ?

• Ton modèle est souple, les champs peuvent évoluer ou varier.

• Tu manipules des documents, logs, JSON, objets semi-structurés.

• Tu veux itérer vite, sans gérer des migrations de schéma à chaque changement.

• Tu vises de la scalabilité horizontale ou des volumes massifs.

• Ton application est agnostique : API, prototypage, MVP, micro-service flexible.

En clair : MongoDB offre un cadre rapide, flexible et évolutif => parfait pour les projets dynamiques.

Un petit exemple comme comparatif

On part sur un classique :

Pour chaque utilisateur actif, calculer le CA total (somme des commandes payées) sur les 30 derniers jours, ne garder que ceux dont le total est > 500 €, trier par CA décroissant, et retourner seulement les 10 meilleurs.

Schéma simplifié

Table / collection users

• id

• name

• active (booléen)

Table / collection orders

• id

• user_id

• status (par ex. paid, pending, etc.)

• total_amount (NUMERIC ou double)

• created_at (timestamp / date)

Version PostgreSQL (SQL)

SELECT 
    u.id AS user_id,
    u.name,
    SUM(o.total_amount) AS total_revenue
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE 
    u.active = TRUE
    AND o.status = 'paid'
    AND o.created_at >= NOW() - INTERVAL '30 days'
GROUP BY 
    u.id, u.name
HAVING 
    SUM(o.total_amount) > 500
ORDER BY 
    total_revenue DESC
LIMIT 10;

Ce que fait cette requête :

1. JOIN entre users et orders.

2. WHERE :

   • utilisateur actif,

   • commande payée,

   • date dans les 30 derniers jours.

3. GROUP BY par utilisateur.

4. HAVING pour filtrer sur l’agrégat SUM(...) > 500.

5. ORDER BY puis LIMIT 10.

Tout est déclaratif, centré sur les relations et les agrégats.

Version MongoDB (aggregation pipeline)

On suppose :

• orders contient les commandes,

• users est une autre collection,

• on référence l’utilisateur via user_id.

db.orders.aggregate([
  // 1. On filtre les commandes pertinentes
  {
    $match: {
      status: "paid",
      created_at: {
        $gte: new Date(Date.now() - 30  24  60  60  1000) // 30 derniers jours
      }
    }
  },
  // 2. On joint avec les utilisateurs
  {
    $lookup: {
      from: "users",
      localField: "user_id",
      foreignField: "id",
      as: "user"
    }
  },
  // 3. $lookup renvoie un tableau, on le “déplie”
  {
    $unwind: "$user"
  },
  // 4. On ne garde que les utilisateurs actifs
  {
    $match: {
      "user.active": true
    }
  },
  // 5. On groupe par utilisateur
  {
    $group: {
      _id: {
        user_id: "$user.id",
        name: "$user.name"
      },
      total_revenue: { $sum: "$total_amount" }
    }
  },
  // 6. Equivalent du HAVING
  {
    $match: {
      total_revenue: { $gt: 500 }
    }
  },
  // 7. Tri
  {
    $sort: {
      total_revenue: -1
    }
  },
  // 8. Limite
  {
    $limit: 10
  },
  // 9. Projection finale plus propre
  {
    $project: {
      _id: 0,
      user_id: "$_id.user_id",
      name: "$_id.name",
      total_revenue: 1
    }
  }
]);

Équivalences grossières :

• FROM orders JOIN users → $lookup + $unwind

• WHERE → $match

• GROUP BY → $group

• HAVING → $match après le $group

• ORDER BY → $sort

• LIMIT → $limit

Et Laravel dans tout ça ?

L’un des avantages de Laravel, c’est sa flexibilité : le framework s’adapte très bien à différents types de bases.

Avec PostgreSQL

Tu profites du duo classique :

Eloquent + Query Builder + Migrations + Relations.

Tout est natif, éprouvé, documenté. Rien à bricoler.

Avec MongoDB

Grâce à des drivers et packages spécialisés, tu peux utiliser MongoDB tout en gardant l’esprit Laravel : modèles, requêtes, collections adaptées au NoSQL.

Ce n’est pas "par défaut", mais c’est parfaitement faisable.

En bref : Laravel ne t’impose rien. À toi de choisir la meilleure base pour ton domaine métier.

Choisir une base, c’est choisir les fondations de ton application

Le choix de la base de données n’est pas un simple détail technique. C’est un choix d’architecture, un choix stratégique. PostgreSQL et MongoDB offrent tous deux des avantages solides et éprouvés.

Prends le temps de :

1. Analyser la nature de tes données,

2. Anticiper l’évolution de ton modèle,

3. Evaluer les volumes,

4. Définir ton besoin métier,

5. Réfléchir à la scalabilité.

La bonne base, c’est celle qui te permettra de développer une application solide, évolutive et adaptée à son usage réel. Choisis en conscience : ton futur toi (et ton futur projet) te remercieront.