Types de bases de données - SQL, NoSQL, et quand je choisis vraiment chacune

Un « type de base » n'est pas une marque. PostgreSQL et MySQL sont toutes deux relationnelles. MongoDB et Firestore sont des bases document. Redis est un moteur clé-valeur que les équipes traitent comme cache, file, et parfois comme dépôt primaire dangereux. Choisir une base parce qu'un tuto l'utilise, c'est choisir une mode. La choisir selon la forme des données et les requêtes de l'app, c'est de l'architecture.

C'est la carte que j'utilise quand on demande « SQL ou NoSQL ? » - souvent la mauvaise première question. La première : qu'est-ce qu'une ligne (ou un document, ou un nœud) dans ce produit, qu'est-ce qui doit rester cohérent, et quelles questions l'app posera mille fois par jour ?

1. Ce que « type » veut vraiment dire

Trois axes comptent plus que la catégorie marketing. Si vous vous trompez là, le logo sur la boîte ne vous sauvera pas.

• Modèle de données : tables avec relations, documents imbriqués, clés, graphes, seaux temporels ou vecteurs.
• Modèle de requête : jointures, filtre par champ, get-by-key, parcours de graphe, plage temporelle, ou « qu'est-ce qui est proche de cet embedding ? »
• Garanties : transactions ACID, cohérence éventuelle, simplicité d'un nœud contre un cluster que vous déboguez à 2 h du matin.

2. Relationnel (SQL) - le standard pour l’argent et les relations

PostgreSQL, MySQL, SQLite. Lignes dans des tables, clés étrangères, jointures, migrations, transactions ACID. C'est encore le bon foyer pour la plupart des produits web : utilisateurs, espaces de travail, rôles, commandes, factures, réservations, stock. Si une ligne doit exister parce qu'une autre existe, ou qu'un débit ne doit pas passer deux fois, il vous faut un moteur relationnel - pas un blob JSON et une prière.

PostgreSQL est mon standard en 2026 : JSONB quand un champ est vraiment sans schéma, full-text intégré pour une petite recherche, pgvector quand le RAG arrive plus tard. On peut grandir longtemps avant d'« avoir besoin » d'une deuxième base. SQLite est sous-estimé pour le local-first, les CLI et les tout petits produits. MySQL convient si l'équipe le fait déjà tourner - je ne démarre pas un projet neuf là.

• Choisissez SQL quand la tâche, c'est l'intégrité, les rapports avec jointures, et « qui a payé quoi dans cet espace de travail ».
• Ne choisissez pas SQL parce que c'est « enterprise ». Choisissez-le parce que le domaine est un graphe de faits qui doivent rester vrais ensemble.

3. Bases document - objets flexibles, relations coûteuses

MongoDB, CouchDB, Firestore, DynamoDB en mode document. Un document est un arbre JSON. Ça colle quand l'unité de travail est un objet avec des morceaux imbriqués toujours chargés ensemble : un article CMS, un produit avec un sac d'attributs, un profil utilisateur que vous chargez toujours entier.

Le piège : vous avez quand même des utilisateurs, des espaces de travail et des factures. Vous réinventerez les jointures dans l'app, perdrez les transactions multi-documents (ou les paierez), et passerez un an à ajouter des règles d'unicité qu'un moteur relationnel vous aurait données le premier jour. J'utilise une base document quand le produit a la forme du contenu et le schéma d'accès est « charger ce blob par id ». Pas parce que le frontend parle JSON. Postgres JSONB parle déjà JSON.

4. Clé-valeur - Redis et les autres

Redis, Memcached, DynamoDB en dépôt clé-valeur pur. Get, set, expire. Listes, ensembles, pub/sub en option. Ce n'est pas là que vit le système de record. C'est la couche rapide à côté.

• Bien : sessions, limites de débit, drapeaux de fonctionnalités, clés d’idempotence, cache de lectures chères, verrous courts.
• Mauvais : la seule copie des commandes, utilisateurs ou permissions. Un flush ou une politique d'éviction - et c'est un cauchemar support.

5. Wide-column - quand les écritures ne s’arrêtent jamais

Cassandra, Scylla, Bigtable. On partitionne par clé, on écrit beaucoup, on lit par cette clé, et on accepte que le SQL ad hoc n'est pas le sujet. Juste pour de la télémétrie à énorme échelle, des fils type boîte de réception, des charges très écriture multi-région. Faux pour un SaaS de réservation à douze tables. Si vous n'avez pas déjà un chiffre du genre « millions d'écritures par seconde », sautez la catégorie. Le coût d'exploitation du cluster est le produit.

6. Graphe - quand la question est la connexion

Neo4j, Amazon Neptune, et - pour les petits graphes - SQL avec des CTE récursives. Un moteur graphe quand le produit est le réseau : reco, cercles de fraude, organigrammes, héritage de permissions, « qui est à deux sauts de ce fournisseur ». Pas parce que vous avez dessiné des boîtes et des flèches au tableau. Presque chaque domaine a des relations. Les bases relationnelles les modélisent déjà. Les moteurs graphe gagnent leur place quand la profondeur de parcours est la requête, pas le diagramme de schéma.

7. Time-series - métriques, capteurs, événements dans le temps

InfluxDB, TimescaleDB, Prometheus pour l'ops, ClickHouse pour les événements en forme d'analytics. Si chaque ligne est « ce device ou cette métrique à ce timestamp », un schéma OLTP général fera mal : trop d'inserts, scans de plage, politiques de rétention. TimescaleDB séduit parce que ça reste PostgreSQL - mêmes sauvegardes, même SQL, hypertables pour le chemin chaud. ClickHouse, c'est de l'analytics, pas la transaction de caisse. Ne versez pas votre table commandes dans un moteur time-series parce que created_at existe.

8. Vecteur - embeddings, pas un second référentiel

Pinecone, Qdrant, Weaviate, et pgvector dans Postgres. On stocke des vecteurs pour demander « quel texte est proche de cette question ? » C'est du RAG, de la recherche sémantique, de la déduplication. L'article, le prix, l'utilisateur vivent toujours dans la base opérationnelle. L'index vectoriel est un index dérivé, comme la recherche. On le reconstruit. Ne faites pas dépendre la caisse ou les permissions de lui.

En 2026 j'ajoute d'abord pgvector à Postgres. Une base vectorielle dédiée quand la taille du corpus et le QPS justifient une pièce mobile de plus - pas parce qu'un pitch deck a dit « AI-native ».

9. La recherche n’est pas un système de record

Elasticsearch, OpenSearch, Typesense, Meilisearch. Full-text, tolérance aux fautes, facettes, classement. Reconstruire depuis le référentiel. Ne faites jamais dépendre caisse, stock ou permissions d'un index qui peut dériver après un réindex raté. Le full-text Postgres suffit à beaucoup de petits catalogues. Ajoutez un moteur de recherche quand les utilisateurs tapent des requêtes sales et qu'il vous faut de la pertinence - pas quand SQL vous ennuie.

10. Comment je choisis vraiment

Je passe les filtres dans cet ordre. La stack vient après les réponses, pas avant le tableau de comparaison.

• Quelle est l'unité de cohérence ? Si l'argent ou le stock bouge : SQL avec transactions. Pas « on corrigera les doubles dans l'app ».
• Quelle est la requête chaude ? Par id, jointure, full-text, similarité, plage temporelle ou saut de graphe ? Accrocher le moteur à cette forme.
• Qui l'exploite à 2 h du matin ? Un Postgres managé bat un cluster malin que personne dans l'équipe ne sait déboguer.
• Un moteur couvre-t-il 80 % ? Postgres plus Redis couvrent la plupart des produits web que je mets vraiment en prod.

Un standard 2026 par lequel je commencerais vraiment

Tant que le modèle de données n'impose pas un spécialiste dès le premier jour, j'ouvrirais avec cette stack - et je refuserais de l'étendre tant qu'un goulot mesuré n'apparaît pas, pas un article de blog.

• PostgreSQL comme référentiel. JSONB là où un champ est vraiment sans schéma. pgvector si le RAG est une vraie fonctionnalité, pas une slide.
• Redis pour cache, sessions, limites de débit et files légères. Pas pour les commandes.
• Stockage objet pour les fichiers. Un moteur de recherche seulement quand LIKE et le FTS Postgres ne suffisent plus.

Le type, c’est la forme de la tâche

SQL contre NoSQL, c'était un débat des années 2010. La question utile en 2026 : quel modèle de données colle à la tâche, et combien de systèmes pouvez-vous bien opérer - le moins possible. Partez d'un référentiel relationnel. Ajoutez un dépôt spécialiste quand la forme de requête est vraiment différente - cache, recherche, vecteurs, time-series. L'hybride est normal. Cinq bases le jour un d'un MVP, c'est comme ça que l'expérience meurt.