En 2026, PostgreSQL est le choix pragmatique par défaut pour la plupart des nouveaux projets web : il combine la fiabilité du SQL, les jointures, les transactions ACID, JSONB, la recherche plein texte et des extensions utiles comme pgvector. MySQL reste un excellent choix lorsque l'équipe le maîtrise déjà. MongoDB devient pertinent lorsque les données sont réellement orientées documents, avec des structures très variables. Le bon choix ne dépend donc pas d'une mode, mais du modèle de données, des requêtes à exécuter et des compétences de l'équipe.
Pour un développeur, choisir une base de données revient d'abord à répondre à une question simple : quelles garanties le produit doit-il offrir quand les données évoluent, sont consultées ou reliées entre elles ? Une application de gestion, un SaaS avec abonnements ou un site e-commerce n'ont pas les mêmes contraintes qu'un CMS éditorial ou qu'un catalogue aux attributs changeants. Ce guide aide à décider concrètement entre SQL, NoSQL, PostgreSQL, MySQL et MongoDB.
Choisir une base de données en 2026 : la réponse courte
Pour un nouveau projet métier, un SaaS, une plateforme e-commerce ou un back-office, PostgreSQL constitue généralement le meilleur point de départ. Son modèle relationnel rend les données cohérentes, ses transactions sécurisent les opérations sensibles et ses requêtes permettent d'explorer des relations complexes entre utilisateurs, produits, commandes, droits ou historiques.
MySQL demeure une solution relationnelle éprouvée et largement déployée. Il est particulièrement raisonnable de le conserver ou de le choisir lorsque l'équipe, l'infrastructure et les habitudes de développement reposent déjà sur lui. Changer de moteur sans besoin fonctionnel réel crée rarement de la valeur. Pour un backend Node.js qui démarre tout juste, le guide de définition de Node.js pour débutant pose les bases avant même de se poser la question du choix de base de données.
MongoDB ne doit pas être vu comme une version plus moderne du SQL, ni comme une solution automatique à tous les problèmes de souplesse. Son modèle documentaire est adapté lorsque l'application manipule naturellement des documents aux champs variables, par exemple un catalogue dont chaque type de produit possède ses propres attributs, un CMS ou un event store. Si les besoins centraux sont les jointures, l'intégrité référentielle, les droits, la facturation et l'historique, une base relationnelle reste souvent plus simple à faire évoluer.
SQL ou NoSQL : comprendre la différence utile
Le débat SQL contre NoSQL est souvent mal posé. Il ne s'agit pas de classer les technologies entre anciennes et nouvelles, mais de choisir une manière de représenter les données. Les bases SQL, telles que PostgreSQL et MySQL, organisent généralement les informations dans des tables reliées entre elles. Les bases orientées documents, comme MongoDB, stockent des documents qui regroupent des données de manière plus flexible.
Le SQL est particulièrement adapté lorsque la cohérence doit être garantie. Une transaction ACID permet, par exemple, de traiter une opération comme un tout cohérent : la création d'une commande, l'enregistrement de son paiement, la mise à jour de son statut et l'écriture de son historique ne doivent pas laisser le système dans un état intermédiaire incohérent. Cette logique est centrale dans les applications métier, la fintech, le e-commerce, les outils de gestion et les produits SaaS.
Les jointures constituent un autre atout relationnel majeur. Elles permettent de rapprocher des données liées sans les dupliquer systématiquement : retrouver les commandes d'un client, les droits associés à un utilisateur, les abonnements actifs d'une entreprise ou les produits d'une catégorie. Pour les requêtes métier, les tableaux de bord et les analyses opérationnelles, cette capacité évite de déplacer une complexité importante dans le code applicatif.
MongoDB apporte une autre forme de souplesse. Un document peut évoluer rapidement et contenir des champs différents d'un enregistrement à l'autre. Cette flexibilité convient à un contenu éditorial dont les blocs diffèrent selon les pages, à un catalogue comprenant des familles de produits hétérogènes ou à des prototypes dont le modèle change fréquemment.
- Préférez SQL si les données sont reliées, si les règles métier doivent rester strictes, si les requêtes sont complexes ou si la cohérence transactionnelle est essentielle.
- Envisagez MongoDB si le produit manipule avant tout des documents autonomes, aux structures très variables, et si cette souplesse correspond à la réalité métier.
- Évitez de choisir sur la seule vitesse supposée : les performances dépendent surtout des requêtes, des index, du volume, de l'architecture et de l'exploitation.
PostgreSQL, MySQL, MongoDB : comparatif pour décider
| Critère | PostgreSQL | MySQL | MongoDB |
|---|---|---|---|
| Modèle principal | Relationnel SQL | Relationnel SQL | Documents NoSQL |
| Usage recommandé en 2026 | Choix pragmatique par défaut pour la majorité des projets web | Choix solide pour les équipes déjà familiarisées avec MySQL | Cas où le modèle documentaire ou très évolutif est réellement justifié |
| Cohérence et transactions | ACID, adapté aux règles métier fortes | ACID, adapté aux applications relationnelles | À évaluer selon le modèle documentaire |
| Relations et requêtes complexes | Très adapté aux jointures et requêtes métier | Adapté aux usages relationnels courants | Moins naturel si les relations croisées structurent le métier |
| Schéma souple | Possible avec JSONB, en conservant le relationnel | Relationnel avant tout | Atout central du modèle documentaire |
| Fonctions mises en avant | JSONB, recherche plein texte, PostGIS, pgvector | Écosystème relationnel largement déployé | Documents et évolution rapide du modèle |
| Exemples de projets | SaaS, application métier, e-commerce, IA avec vecteurs | E-commerce ou application métier en contexte MySQL | CMS, catalogue à attributs variables, event store, prototype |
Ce tableau ne remplace pas l'analyse d'un projet réel, mais il permet d'éviter deux erreurs fréquentes. La première consiste à adopter MongoDB pour éviter de concevoir un schéma de données. La seconde consiste à imposer un modèle relationnel extrêmement rigide à un contenu qui évolue chaque semaine et dont les champs varient profondément selon les cas.
La distinction n'est pas toujours absolue. PostgreSQL, grâce à JSONB, peut stocker des données semi-structurées tout en conservant les atouts d'une base relationnelle. Cela en fait une option particulièrement polyvalente quand une partie du modèle est stable et reliée, mais que certains attributs doivent rester souples. Le choix doit se faire sur les opérations réelles du produit, non sur une opposition théorique entre tables et documents.
Quel choix selon le type de projet ?
SaaS et application métier
Pour un SaaS, une application de gestion, un outil RH, une plateforme B2B ou un logiciel interne, PostgreSQL est généralement le choix le plus cohérent. Ces produits manipulent souvent des utilisateurs, des organisations, des rôles, des abonnements, des droits d'accès, des factures, des événements et des historiques. Ces entités sont liées entre elles et doivent respecter des règles métier précises.
Les transactions et les relations permettent de préserver une vision fiable du système. Une entreprise ne doit pas se retrouver avec un abonnement actif sans client associé, une facture sans ligne de facturation ou un droit attribué à un compte supprimé. Le modèle relationnel aide à représenter ces dépendances au niveau de la base, plutôt que de les laisser uniquement à la charge du code applicatif.
E-commerce
Pour un site e-commerce, PostgreSQL ou MySQL sont les deux options raisonnables. Le choix dépend largement de l'expérience de l'équipe. Les commandes, paiements, stocks, clients et promotions impliquent des données liées et des opérations pour lesquelles la cohérence est essentielle. PostgreSQL apporte une grande polyvalence, tandis que MySQL reste pertinent dans une organisation qui le déploie, le supervise et l'optimise déjà avec efficacité.
Un catalogue e-commerce très hétérogène peut contenir des attributs variables : dimensions, matières, compatibilités, tailles ou caractéristiques techniques. Cela ne signifie pas automatiquement qu'il faut basculer vers MongoDB. PostgreSQL et JSONB peuvent constituer un point de départ utile lorsqu'il faut concilier un socle relationnel solide avec une partie de données flexible.
CMS et catalogues aux données variables
MongoDB est pertinent lorsqu'un contenu ou un catalogue est naturellement structuré comme un ensemble de documents. Un CMS peut stocker des pages composées de blocs différents, dont les champs évoluent rapidement. Un catalogue peut réunir des objets dont les caractéristiques ne se recouvrent presque pas. Dans ces cas, vouloir normaliser chaque variation dans de nombreuses tables peut ralentir l'évolution du produit.
Le critère décisif reste la structure réelle des accès aux données. Si les documents sont principalement lus, modifiés et affichés comme des objets cohérents, MongoDB peut être bien adapté. Si l'application doit constamment croiser ces données avec des utilisateurs, contrats, commandes, droits et rapports métier, le coût des relations doit être étudié avant de choisir une base documentaire.
Produit avec IA, recherche sémantique ou vecteurs
Pour un produit nécessitant de la recherche vectorielle ou sémantique, PostgreSQL associé à pgvector constitue un point de départ pragmatique en 2026. Cette approche permet de garder les données applicatives, leurs droits d'accès et les informations nécessaires à la recherche dans un environnement relationnel polyvalent, tout en ajoutant la capacité de travailler avec des vecteurs.
Le choix ne dispense pas de concevoir les flux de données, les requêtes et les accès. Une fonction de recherche sémantique doit rester reliée aux règles du produit : qui peut consulter quel document, quels contenus sont actifs, quelles informations doivent être filtrées selon l'organisation ou le rôle de l'utilisateur.
- SaaS, back-office, application métier : PostgreSQL.
- E-commerce : PostgreSQL ou MySQL selon les compétences de l'équipe.
- CMS et catalogue à attributs très variables : MongoDB si le modèle documentaire est naturel.
- Recherche vectorielle ou produit IA : PostgreSQL avec pgvector comme point de départ.
- Sessions, cache, données à accès rapide : Redis en complément de la base principale.
Pourquoi PostgreSQL est la référence pragmatique
PostgreSQL est souvent recommandé par défaut non parce qu'il conviendrait à toutes les situations, mais parce qu'il couvre un spectre très large de besoins sans imposer trop tôt une architecture spécialisée. Il offre le socle relationnel attendu pour les applications qui ont besoin de cohérence, de relations et de requêtes riches. Il propose également des fonctions modernes qui évitent parfois de multiplier les composants dès la première version d'un produit.
JSONB est l'un des éléments qui renforcent cette polyvalence. Il permet de conserver des données au format JSON dans PostgreSQL. Pour un projet, cela peut être utile lorsqu'une entité contient un noyau stable et relationnel, accompagné d'attributs qui évoluent plus vite. L'objectif n'est pas de transformer toutes les tables en documents JSON, mais de garder de la flexibilité là où elle apporte une valeur concrète.
La recherche plein texte est un autre outil intégré qui peut répondre à des besoins de recherche applicative. Les extensions renforcent encore le champ des possibles. PostGIS est destiné aux données géographiques, tandis que pgvector répond aux usages de recherche vectorielle et d'IA. Leur présence ne signifie pas qu'il faut concentrer tous les besoins dans une seule base sans réflexion, mais elles permettent de commencer avec une architecture lisible.
En 2026, les offres managées telles que Supabase et Neon sont mises en avant pour simplifier le déploiement de PostgreSQL et mieux accompagner un trafic variable. Pour une petite équipe, elles réduisent une partie de la charge opérationnelle liée à l'installation et à l'exploitation d'une base. Cela ne retire pas la responsabilité de concevoir le schéma, les accès et les requêtes, mais cela peut accélérer le démarrage d'un projet.
MySQL et MongoDB : les choisir pour de bonnes raisons
MySQL reste un moteur relationnel fiable et massivement présent dans les environnements web. Il n'est simplement pas le choix le plus souvent retenu par défaut pour un nouveau projet en 2026, au regard de la polyvalence attribuée à PostgreSQL. Cette nuance compte : un choix par défaut n'est pas un verdict d'obsolescence.
Une équipe qui connaît MySQL, dispose de procédures d'exploitation établies et maîtrise ses pratiques de développement a de bonnes raisons de poursuivre avec cette technologie. Le meilleur moteur de base de données est aussi celui que les développeurs et les équipes d'exploitation savent utiliser correctement. Réécrire des procédures, migrer des données et former toute une équipe peut coûter davantage que le bénéfice attendu d'un changement de moteur.
MongoDB est le leader des bases NoSQL orientées documents dans ce comparatif. Son intérêt apparaît lorsque la structure documentaire correspond au domaine métier. Il peut faciliter l'évolution d'un prototype rapide, d'un CMS ou d'un catalogue fortement hétérogène. En revanche, le choisir uniquement parce qu'un schéma souple semble plus facile au début expose à une difficulté ultérieure : les relations, les règles de cohérence et les besoins de reporting ne disparaissent pas parce qu'ils ne sont pas modélisés dans des tables.
Une base de données flexible ne remplace pas la modélisation. Elle déplace la manière dont les règles et les structures sont exprimées.
Avant de retenir MongoDB, une équipe peut se poser quelques questions directes : les données sont-elles vraiment des documents autonomes ? Les champs changent-ils fréquemment et profondément selon les objets ? Les cas d'usage reposent-ils davantage sur la lecture et l'écriture d'un document que sur des jointures métier ? Si la réponse est négative ou incertaine, PostgreSQL est souvent le choix le plus prudent.
ORM, cache et compétences : construire une architecture durable
Le choix de la base de données ne se limite pas au moteur. Il influence la manière de modéliser les données, d'écrire les migrations, de surveiller les requêtes et de faire évoluer le produit. En 2026, la tendance côté ORM consiste à éviter les couches d'abstraction trop opaques. Un ORM est utile s'il facilite le typage, les relations et les migrations, mais il ne doit pas empêcher l'équipe de comprendre les requêtes réellement exécutées.
Dans l'écosystème Node.js et TypeScript, Prisma, Drizzle et TypeORM font partie des outils cités. Ils peuvent accélérer le développement, à condition de conserver une couche fine et lisible. Les requêtes complexes, les besoins de performance et les choix d'indexation demandent toujours une maîtrise du modèle SQL et du comportement de la base.
- Utilisez l'ORM pour les opérations courantes, les migrations, le typage et les relations bien identifiées.
- Gardez la possibilité d'écrire et de lire des requêtes explicites lorsque le besoin métier ou la performance l'exige.
- Examinez les requêtes coûteuses au lieu de supposer que l'ORM les optimisera automatiquement.
- Faites évoluer le schéma avec des migrations compréhensibles et versionnées.
Redis occupe une place différente. Il sert de complément pour le cache, les sessions ou certaines données nécessitant un accès rapide. Il ne remplace pas la base principale d'une application métier. Les données qui doivent être durables, cohérentes et interrogeables selon les règles du produit doivent rester dans le système de référence choisi, par exemple PostgreSQL ou MySQL.
Cette spécialisation reste valorisée sur le marché de l'emploi. Pour 2026, Jobijoba situe le salaire moyen brut annuel d'un développeur bases de données ou DBA autour de 45 500 €, avec une fourchette de 42 000 à 49 000 € par an. Une autre méthode de calcul mentionne une moyenne de 38 500 €, ce qui illustre les variations selon les périmètres statistiques retenus. Des offres observées sur Jooble pour des DBA se situent dans un ordre de grandeur de 40 000 à 60 000 € annuels selon la spécialité et l'expérience. Ces perspectives de rémunération s'ajoutent à celles détaillées dans le comparatif des salaires développeurs en 2026, pour situer la spécialisation base de données parmi les autres trajectoires backend.
Pour un développeur, la compétence la plus durable n'est pas de connaître un unique produit, mais de savoir identifier les règles métier, modéliser les relations, prévoir les requêtes et conserver la maîtrise des données. PostgreSQL, MySQL et MongoDB sont alors des outils à utiliser selon leur domaine de pertinence, plutôt que des étiquettes à défendre. Pour approfondir les choix d'architecture backend qui accompagnent cette réflexion, le guide complet du backend JavaScript avec Node.js détaille les frameworks et pratiques qui consomment ces bases de données au quotidien.