Types de bases de données : relationnelle, columnar, document, graphe, vecteur et plus

Ce que signifie vraiment « type de base de données »

Un « type de base de données » n'est pas qu'une étiquette : c'est un raccourci pour la façon dont un système stocke les données, comment vous les interrogez et ce pour quoi il est optimisé. Ce choix influe directement sur la vitesse (ce qui est rapide vs lent), le coût (matériel ou cloud) et les capacités (transactions, analytique, recherche, réplication, etc.).

Pourquoi le « type » compte

Différents types de bases de données font des compromis différents :

• Une base relationnelle est excellente quand vos données sont structurées et que vous avez besoin de transactions fiables.
• Une base columnar brille lorsque vous scannez beaucoup de lignes pour répondre à des questions analytiques.
• Une base de documents peut évoluer plus vite quand la forme des données de votre appli change souvent.
• Une base graphe est conçue pour des données riches en relations.
• Une base vectorielle se concentre sur la « similarité » plutôt que sur la correspondance exacte.

Ces choix de conception influencent :

• Les schémas de requêtes : beaucoup de petites recherches, jointures complexes ou gros scans analytiques ?
• Le modèle d'échelle : monter en gamme sur une grosse machine, ou s'étendre horizontalement ?
• Le modèle de données : tables, documents, paires clé-valeur, graphes, vecteurs, ou points horodatés.

Ce que vous apprendrez dans ce guide

Cet article parcourt les principaux types de bases de données et explique, pour chacun :

• Ce pour quoi il est le mieux adapté (et ses limites)
• Des cas d'usage typiques dans des produits réels
• Les compromis clés qui affectent performance, coût et complexité

Petite note sur les systèmes « multi-modèles »

De nombreux produits modernes brouillent les frontières. Certaines bases relationnelles ajoutent le support JSON qui recoupe une base de documents. Des plateformes de recherche et d'analytique proposent de l'indexation vectorielle comme une base vectorielle. D'autres combinent streaming et stockage avec des fonctionnalités de séries temporelles.

Donc « type » n'est pas une boîte stricte : c'est utile pour comprendre les forces par défaut et les types de charges pour lesquels une base est la plus adaptée.

Comment utiliser ce guide pour présélectionner des options

Commencez par votre charge principale :

• Si vous avez besoin de données structurées et de transactions, commencez par une base relationnelle.
• Si vous faites beaucoup de reporting et tableaux de bord, regardez une base columnar ou un entrepôt.
• Si la forme de vos données d'appli change souvent, envisagez une base de documents.
• Si vous avez besoin de recherches extrêmement rapides par clé, un magasin clé-valeur est un bon candidat.

Puis utilisez la section « Comment choisir le bon type de base de données » pour affiner en fonction de l'échelle, des besoins de cohérence et des requêtes que vous exécuterez le plus souvent.

Bases relationnelles (SQL) : le choix par défaut pour les données structurées

Les bases relationnelles sont ce à quoi beaucoup pensent quand on dit « base de données ». Les données sont organisées en tables constituées de lignes (enregistrements) et colonnes (champs). Un schéma définit à quoi ressemble chaque table : quelles colonnes, quels types et comment les tables se relient.

Pourquoi SQL est omniprésent

Les systèmes relationnels sont généralement interrogés avec SQL (Structured Query Language). SQL est populaire car il est lisible et expressif :

• Vous pouvez filtrer et trier (WHERE, ORDER BY).
• Combiner des données entre tables (JOIN).
• Résumer des résultats (GROUP BY).

La plupart des outils de reporting, plateformes d'analytique et applications métier parlent SQL, ce qui en fait un choix sûr quand vous voulez une large compatibilité.

Transactions ACID, en clair

Les bases relationnelles sont connues pour les transactions ACID, qui aident à garder les données correctes :

• Atomicité : un changement multi-étapes est « tout ou rien ».
• Cohérence : les règles (comme les clés étrangères) restent valides après les changements.
• Isolation : les mises à jour simultanées ne se corrompent pas.
• Durabilité : une fois sauvegardées, les données survivent aux crashs.

C'est important quand les erreurs coûtent cher : double facturation d'un client ou perte d'une mise à jour de stock.

Charges adaptées

Une base relationnelle convient généralement aux données structurées et bien définies et à des flux comme :

• Applications métier (CRM/ERP)
• Finance, paiements, facturation
• Stock, commandes, réservations

Pièges fréquents

La même structure qui rend les bases relationnelles fiables peut aussi ajouter des frictions :

• Schémas rigides : des changements fréquents de forme de données peuvent nécessiter des migrations.
• Montée en charge avec jointures : beaucoup de jointures sur de grandes tables peuvent devenir lentes ou coûteuses à grande échelle, surtout si les données sont réparties sur plusieurs machines.

Quand votre modèle de données change constamment — ou que vous avez besoin d'une échelle horizontale extrême avec des accès simples — d'autres types de bases peuvent mieux convenir.

Bases columnaires : conçues pour l'analytique

Les bases columnaires stockent les données « par colonne » plutôt que « par ligne ». Ce seul changement a un grand impact sur la vitesse et le coût pour les charges analytiques.

Row-store vs column-store

Dans un row-store traditionnel (courant en relationnel), toutes les valeurs d'un enregistrement sont stockées ensemble. C'est idéal quand vous récupérez ou mettez à jour un client/une commande à la fois.

Dans un column-store, toutes les valeurs d'un même champ sont stockées ensemble : tous les price, tous les country, tous les timestamp. Cela permet de lire uniquement les colonnes nécessaires pour un rapport, sans charger des lignes entières depuis le disque.

Pourquoi le columnar est rapide pour le reporting

Les requêtes BI effectuent souvent :

• Le scan de nombreux enregistrements
• La sélection d'un petit nombre de colonnes
• Le calcul d'agrégats comme SUM, AVG, COUNT et des groupements

Le stockage par colonne accélère ces motifs parce qu'il lit moins de données et compresse très bien (des valeurs similaires regroupées compressent efficacement). De nombreux moteurs columnar utilisent aussi l'exécution vectorisée et l'indexation/partitionnement intelligents pour accélérer les gros scans.

Motifs de requêtes typiques

Les systèmes columnar excellent pour les tableaux de bord et le reporting : « chiffre d'affaires par semaine », « top 20 produits par région », « taux de conversion par canal », ou « erreurs par service sur les 30 derniers jours ». Ces requêtes touchent beaucoup de lignes mais peu de colonnes.

Compromis : mises à jour OLTP et lookups point-à-point

Si votre charge consiste surtout à « récupérer un enregistrement par ID » ou « mettre à jour une seule ligne des dizaines de fois par seconde », le columnar peut paraître plus lent ou plus coûteux. Les écritures sont souvent optimisées pour des lots (ingestion en append) plutôt que pour des mises à jour fréquentes et minuscules.

Où il excelle

Les bases columnar sont adaptées pour :

• BI et tableaux de bord
• Analytique de clickstream et d'événements
• Reporting à grande échelle sur logs ou transactions

Si votre priorité est des agrégations rapides sur beaucoup de données, le columnar est souvent le premier type à évaluer.

Bases de documents : schémas flexibles pour les données applicatives

Les bases de documents stockent les données sous forme de « documents » — des enregistrements autonomes ressemblant souvent à du JSON. Au lieu de répartir l'information sur de nombreuses tables, vous gardez généralement les champs liés ensemble dans un objet (y compris des tableaux imbriqués et des sous-objets). Cela en fait un choix naturel pour les données d'application.

Le modèle document (enregistrements de type JSON)

Un document peut représenter un utilisateur, un produit ou un article — avec des attributs qui peuvent différer d'un document à l'autre. Un produit peut avoir size et color, un autre dimensions et materials, sans imposer un schéma unique pour tous.

Cette flexibilité est particulièrement utile quand vos besoins changent fréquemment ou quand différents objets ont des ensembles de champs différents.

Indexation, à haut niveau

Pour éviter de scanner tous les documents, les bases de documents utilisent des index — structures qui aident à localiser rapidement les documents correspondant à une requête. Vous pouvez indexer des champs courants (email, sku, status) et beaucoup de systèmes indexent aussi les champs imbriqués (address.city). Les index accélèrent les lectures mais ajoutent un surcoût aux écritures, car il faut mettre à jour l'index lorsque les documents changent.

Forces et compromis

Les bases de documents excellent pour les schémas évolutifs, les données imbriquées et des payloads orientés API. Les compromis apparaissent surtout quand vous avez :

• Des jointures complexes entre de nombreuses entités (moins naturelles que dans une relationnelle)
• Des transactions multi-documents à grande échelle (prises en charge par beaucoup de produits, mais potentiellement coûteuses)
• Besoin d'une normalisation stricte (les équipes dupliquent parfois des données pour simplifier les lectures, ce qui exige une logique de mise à jour soignée)

Cas d'usage courants

Ils conviennent bien aux systèmes de gestion de contenu, catalogues produits, profils utilisateurs et API backend — partout où vos données correspondent naturellement à « un objet par page/écran/requête ».

Magasins clé-valeur : simples et très rapides pour les lookups

Les magasins clé-valeur sont le modèle le plus simple : vous stockez une valeur (chaîne, blob JSON, etc.) et la récupérez via une clé unique. L'opération centrale est essentiellement « donne-moi la valeur pour cette clé », d'où des optimisations pour être extrêmement rapides.

Le modèle clé-valeur (et pourquoi c'est rapide)

Parce que les lectures et écritures tournent autour d'une clé primaire unique, les magasins clé-valeur peuvent être optimisés pour une latence faible et un débit élevé. Beaucoup gardent les données chaudes en mémoire, minimisent la planification de requêtes complexes et s'étendent horizontalement.

Cette simplicité façonne aussi le modèle de données : au lieu de demander à la DB « trouve tous les utilisateurs à Berlin inscrits la semaine dernière », vous concevez souvent des clés qui pointent déjà vers l'enregistrement exact (user:1234:profile).

Popularité pour le caching et les sessions

Les magasins clé-valeur sont largement utilisés comme cache devant une base plus lente (ex. relationnelle). Si votre appli a besoin souvent des mêmes données — détails produit, permissions, règles de tarification — mettre en cache évite de recalculer ou de re-query.

Ils sont aussi adaptés pour le stockage de sessions (session:<id> -> session data) car les sessions sont lues et mises à jour fréquemment et expirent automatiquement.

TTL, éviction et mémoire vs disque

La plupart des magasins clé-valeur supportent un TTL (time to live) pour que les données expirent sans nettoyage manuel — idéal pour les sessions, tokens one-time et compteurs de rate limit.

Quand la mémoire est limitée, les systèmes utilisent des politiques d'éviction (LRU, etc.) pour supprimer d'anciennes entrées. Certains produits sont axés mémoire, d'autres peuvent persister sur disque pour la durabilité. Le choix dépend de la priorité : vitesse (mémoire) ou rétention/récupération (disque/persistance).

Compromis à connaître

Les magasins clé-valeur excellent quand vous connaissez la clé. Ils sont moins adaptés aux questions ouvertes.

Beaucoup offrent des motifs de requête limités comparés aux bases SQL. Le support des index secondaires (requêter par champs dans la valeur) varie : certains le proposent, d'autres partiellement, et d'autres encouragent à maintenir vos propres clés de recherche.

Cas d'usage courants

Ils conviennent à :

• Rate limiting : compteurs par utilisateur/IP avec fenêtre TTL
• Feature flags : lectures rapides pour décider d'un comportement par utilisateur/cohorte
• Paniers d'achat : mises à jour rapides d'un objet panier par utilisateur/session

Si votre motif d'accès est « fetch/update par ID » et que la latence compte, un magasin clé-valeur est souvent la façon la plus simple d'obtenir une vitesse fiable.

Wide-column : stockage opérationnel scale-out

Les bases wide-column (ou wide-column stores) organisent les données en familles de colonnes. Plutôt que de penser en termes d'une table fixe avec les mêmes colonnes pour chaque ligne, vous regroupez des colonnes liées et pouvez stocker des ensembles de colonnes différents par ligne au sein d'une même famille.

Wide-column vs columnar analytique

Malgré des noms proches, une wide-column DB n'est pas la même qu'une base columnar d'analytique.

Une base columnar stocke chaque colonne séparément pour scanner d'énormes datasets efficacement (bien pour les rapports). Une wide-column est conçue pour des workloads opérationnels à très grande échelle, où il faut écrire et lire beaucoup d'enregistrements rapidement sur de nombreuses machines.

Où elles excellent

Les systèmes wide-column sont conçus pour :

• Fort débit d'écriture (ingestion de nombreux événements par seconde)
• Montée en charge horizontale (ajout de nœuds pour gérer plus de trafic et de données)
• Lectures à latence prévisible quand vous interrogez avec la bonne clé

Motif d'accès typique

Le plus courant est :

• Vous connaissez la partition key (elle décide où les données résident), et
• Vous lisez souvent un intervalle au sein de cette partition (par ex. « tous les events pour le device X entre 10:00–10:05 »).

Cela en fait un bon choix pour les données ordonnées dans le temps et les workloads append-heavy.

Compromis à prévoir

Avec les wide-column, le modèle de données est guidé par les requêtes : vous concevez les tables autour des requêtes exactes dont vous avez besoin. Cela peut impliquer de dupliquer des données pour supporter différents motifs d'accès.

Elles offrent en général peu de jointures et moins d'options de requêtes ad hoc que relationnelles. Si votre appli repose sur des relations complexes et des requêtes flexibles, vous vous sentirez peut-être limité.

Cas d'usage courants

Les wide-column sont souvent utilisées pour IoT events, messagerie et flux d'activité, et autres données opérationnelles à grande échelle où les écritures rapides et les lectures clés-prévisibles sont plus importantes que les requêtes relationnelles riches.

Bases graphe : les relations comme données de première classe

Les bases graphe modélisent les données comme beaucoup de systèmes réels le sont : des choses connectées à d'autres choses. Plutôt que de forcer les relations dans des tables et des tables de jointures, les connexions font partie intégrante du modèle.

Modèle graphe : nœuds, arêtes et propriétés

Un graphe contient généralement :

• Nœuds : entités (personnes, comptes, appareils, produits)
• Arêtes : relations entre eux ("follows", "paid", "belongs to", "shipped to")
• Propriétés : attributs clé-valeur sur nœuds et arêtes (timestamps, montants, labels)

Cela rend naturel la représentation de réseaux, hiérarchies et relations plusieurs-à-plusieurs sans tordre votre schéma.

Pourquoi les traversals peuvent battre les jointures

Les requêtes axées sur les relations nécessitent souvent de nombreuses jointures dans une base relationnelle. Chaque jointure supplémentaire peut ajouter complexité et coût à mesure que les données grandissent.

Les bases graphe sont conçues pour les traversals : parcourir d'un nœud vers ses voisins, puis vers leurs voisins, etc. Quand vos questions ressemblent à « trouve les éléments connectés à N étapes », les traversals restent rapides et lisibles même quand le réseau s'agrandit.

Questions pour lesquelles les graphes excellent

Les graphes sont idéaux pour :

• Chemins et degrés de séparation (plus court chemin, atteignabilité)
• Recommandations ("ceux qui ont acheté X ont aussi acheté Y", "amis d'amis")
• Anneaux de fraude et motifs anormaux (appareils, adresses, moyens de paiement partagés)

Compromis à préparer

Le graphe peut représenter un changement pour les équipes : la modélisation diffère, et les langages de requête (Cypher, Gremlin, SPARQL) peuvent être nouveaux. Il faut aussi des conventions claires pour les types et la direction des relations afin de garder le modèle maintenable.

Quand une relationnelle suffit

Si vos relations sont simples, vos requêtes majoritairement filtrage/agrégations, et qu'une poignée de jointures couvre les parties « connectées », une base relationnelle peut rester le choix le plus simple — surtout si les transactions et le reporting fonctionnent déjà bien.

Bases vectorielles : recherche par similarité pour les applications IA

Les bases vectorielles ciblent un type de question : « Quels éléments sont les plus similaires à celui-ci ? » Au lieu de matcher des valeurs exactes (ID ou mots-clés), elles comparent des embeddings — représentations numériques de contenu (texte, images, audio, produits) générées par des modèles d'IA. Les éléments de sens proche ont des embeddings proches dans un espace multi-dimensionnel.

Pourquoi les vecteurs activent la recherche sémantique

Une recherche classique peut manquer des résultats si la formulation diffère (« laptop sleeve » vs « notebook case »). Avec des embeddings, la similarité se base sur le sens, permettant de trouver des résultats pertinents même quand les mots précis ne correspondent pas.

Opérations cœur : similarité + filtres

L'opération principale est la recherche des plus proches voisins : donné un vecteur de requête, récupérer les vecteurs les plus proches.

Dans les applications réelles, on combine souvent la similarité avec des filtres, par exemple :

• Ne montrer que des documents d'un client spécifique
• Limiter à une catégorie de produits ou langue
• Exclure les éléments archivés ou de faible qualité

Ce motif « filtre + similarité » rend la recherche vectorielle pratique pour des datasets réels.

Où se positionnent les bases vectorielles

Usages courants :

• RAG (Retrieval-Augmented Generation) : récupérer les passages pertinents avant qu'un LLM réponde
• Recherche sémantique : base de connaissances, tickets de support, docs internes
• Recommandations : « les utilisateurs ont aussi vu/acheté » basées sur la similarité de contenu

Compromis à connaître

La recherche vectorielle repose sur des index spécialisés. Construire et mettre à jour ces index peut demander du temps et de la mémoire. Vous choisirez souvent entre meilleur rappel (trouver plus de bons matchs) et latence plus faible (réponses plus rapides).

Apparier avec relationnel ou document

Les bases vectorielles remplacent rarement la DB principale. Une configuration courante : stocker la source de vérité (ordres, utilisateurs, documents) dans une base relationnelle ou document, stocker embeddings + index dans la base vectorielle, puis joindre les résultats vers la source principale pour obtenir les enregistrements complets et vérifier les permissions.

Bases séries temporelles : optimisées pour des métriques dans le temps

Les bases séries temporelles (TSDB) sont conçues pour des données qui arrivent en continu et sont toujours associées à un timestamp. Pensez à l'utilisation CPU toutes les 10 secondes, latence d'API par requête, relevés de capteurs chaque minute, ou prix boursiers changeant plusieurs fois par seconde.

À quoi ressemble une donnée temporelle

La plupart des enregistrements séries temporelles combinent :

• Timestamp : moment de la mesure
• Métrique/valeur : le nombre mesuré (latence, température, prix)
• Tags/labels : métadonnées pour filtrer et grouper (host=web-01, region=us-east, service=checkout)

Cette structure facilite des questions comme « taux d'erreur par service » ou « comparer la latence par région ».

Fonctionnalités de performance des TSDB

Parce que le volume peut croître rapidement, les TSDB se concentrent souvent sur :

• Compression : stocker efficacement de longues séries numériques
• Politiques de rétention : expiration automatique des anciennes données (ex. raw 7 jours, agrégats 90 jours)
• Downsampling : regrouper les détails en résumés (seconde → minute → heure)

Ces fonctions maintiennent les coûts de stockage et de requêtes prévisibles sans nettoyage manuel constant.

Motifs de requêtes communs

Les TSDB excellent pour des calculs temporels, comme :

• Moyennes glissantes (ex. moyenne sur 5 minutes)
• Percentiles (p95/p99 latency)
• Taux de changement (requêtes/seconde)
• Alerting sur seuils ou anomalies

Où elles conviennent (et où non)

Cas typiques : monitoring, observabilité, IoT/senseurs, données financières à haute fréquence.

Le compromis : les TSDB ne sont pas idéales pour des relations ad hoc complexes entre de nombreuses entités (ex. jointures imbriquées « users → teams → permissions → projects »). Pour cela, une base relationnelle ou graphe est souvent plus adaptée.

Entrepôts et lakehouses : analytique à l'échelle organisationnelle

Un data warehouse est moins un type unique de DB qu'une charge de travail + architecture : de nombreuses équipes interrogent de grosses données historiques pour répondre à des questions métier (tendances de revenu, churn, risque de stock). Vous pouvez l'acheter en tant que service managé, mais ce qui fait un warehouse, c'est l'usage : centralisé, analytique et partagé.

Ingestion batch vs streaming (version simple)

La plupart des entrepôts acceptent les données de deux manières :

• Ingestion batch : données tous les heures/jours (exports nocturnes). Moins coûteux et simple, mais pas temps réel.
• Ingestion streaming : événements en continu (clicks, paiements, IoT). Donne des chiffres plus frais, mais demande plus d'outillage et de surveillance.

Pourquoi ils sont rapides : stockage columnar, partitionnement, vues matérialisées

Les entrepôts sont optimisés pour l'analytique avec quelques astuces :

• Stockage columnar lit seulement les colonnes nécessaires pour un rapport.
• Partitionnement segmente les grandes tables par temps ou région pour scanner moins de données.
• Vues matérialisées sauvegardent des résultats pré-calculés (ex. "ventes journalières par pays") pour accélérer les dashboards.

La gouvernance n'est pas optionnelle à l'échelle

Quand plusieurs départements s'appuient sur les mêmes chiffres, vous aurez besoin de contrôle d'accès (qui voit quoi), traces d'audit (qui a interrogé/changé des données) et lineage (d'où vient un indicateur et comment il a été transformé). C'est souvent aussi important que la vitesse des requêtes.

Quand un lakehouse a du sens

Un lakehouse mélange l'analytique type warehouse avec la flexibilité d'un data lake — utile quand vous voulez un seul endroit pour tables curées et fichiers bruts (logs, images, événements semi-structurés) sans tout dupliquer. C'est pertinent quand le volume est élevé, les formats variés, et que vous avez toujours besoin d'un reporting SQL-friendly.

Principaux compromis : cohérence, échelle et motifs de requêtes

Choisir entre types de bases n'est pas une question de « meilleur » absolu mais d'adéquation : que devez-vous interroger, à quelle fréquence, et que se passe-t-il quand une partie du système tombe en panne.

OLTP vs OLAP (faire correspondre la charge)

Règle simple :

• OLTP (transactions en ligne) : beaucoup de petites lectures/écritures (checkout, logins, mises à jour de commande). Priorités : faible latence, mises à jour correctes, nombreux utilisateurs concurrents.
• OLAP (analytique) : requêtes moins nombreuses mais lourdes scannant beaucoup de lignes (dashboards, tendances). Priorités : agrégations rapides, stockage columnar, séparation compute/storage.

Les bases relationnelles excellent souvent pour l'OLTP ; les systèmes columnar, entrepôts et lakehouses sont courants pour l'OLAP.

CAP en clair

Quand une partition réseau survient, vous ne pouvez généralement pas avoir les trois :

• Cohérence : tout le monde voit les mêmes données immédiatement.
• Disponibilité : le système continue de répondre.
• Tolérance aux partitions : il continue de fonctionner malgré des partitions réseau.

De nombreuses bases distribuées choisissent d'être disponibles pendant les problèmes et de réconcilier ensuite (cohérence éventuelle). D'autres priorisent la correction stricte et refusent certaines requêtes tant que tout n'est pas sain.

Mise à l'échelle : verticale, horizontale et sharding

• Scale-up : machine plus grosse — simple, mais limitée.
• Scale-out : plus de machines — plus de capacité, plus de coordination.
• Sharding : partitionner les données entre nœuds (souvent par customer ID). Augmente l'échelle, mais complexifie les requêtes et transactions cross-shard.

Transactions et concurrence

Si beaucoup d'utilisateurs mettent à jour la même donnée, vous avez besoin de règles claires. Transactions regroupent les étapes en « tout ou rien ». Verrous et niveaux d'isolation empêchent les conflits mais peuvent réduire le débit ; une isolation plus lâche améliore la vitesse mais peut autoriser des anomalies.

Préoccupations opérationnelles (à ne pas négliger)

Prévoyez sauvegardes, réplication et reprise après sinistre tôt. Considérez aussi la facilité de tester des restaurations, surveiller le lag et effectuer des upgrades : ces détails du « jour 2 » comptent souvent autant que la vitesse des requêtes.

Comment choisir le bon type de base de données

Choisir parmi les types de bases importe moins que ce que vous devez faire avec vos données. Une approche pratique consiste à partir de vos requêtes et charges.

1) Partir de vos requêtes (et non de vos données)

Notez les 5–10 opérations principales de votre appli ou équipe :

• Que lisez-vous le plus (lookup simple, filtres, jointures, agrégations, recherche de similarité) ?
• Que rédigez-vous le plus (insert ligne unique, flux d'événements, mises à jour, chargements en masse) ?
• À quelle fraîcheur les résultats doivent-ils être (millisecondes, secondes, minutes) ?

Cela réduit les options bien plus vite qu'une check-list de fonctionnalités.

2) Faites correspondre la DB à la forme des données

Raccourci :

• Champs structurés et constants → base relationnelle
• JSON semi-structuré qui change souvent → document
• Beaucoup de relations à traverser en profondeur → graphe
• Embeddings et recherche nearest-neighbor → vecteur
• Événements/métriques horodatés → séries temporelles
• Tables massives scale-out avec accès prévisible → wide-column
• Get/set très simple par clé → clé-valeur
• Analytique lourde et scans → columnar / entrepôt

3) Clarifiez latence, débit et leviers de coût tôt

Les objectifs de performance définissent l'architecture. Fixez des chiffres (latence p95, lectures/écritures par seconde, rétention). Le coût suit généralement :

• Stockage (données brutes + réplicas)
• Compute (requêtes, ETL/ELT, jobs secondaires)
• Réplication (multi-région, HA)
• Indexation (requêtes plus rapides, surcoût aux écritures)

4) Un tableau de décision simple

Beaucoup d'équipes utilisent deux bases : une pour l'opérationnel (ex. relationnel) et une pour l'analytique (ex. columnar/entreprise). Le bon choix rend vos requêtes les plus importantes plus simples, rapides et économiques à exécuter de manière fiable.

Remarque pratique si vous construisez rapidement des produits

Si vous prototypez ou livrez des fonctionnalités vite, la décision DB est souvent liée à votre workflow de développement. Des plateformes comme Koder.ai (génération d'apps web/back-end/mobile à partir de chat) rendent ce choix plus concret : par exemple, le stack backend par défaut de Koder.ai utilise Go + PostgreSQL, un bon point de départ quand vous avez besoin de correction transactionnelle et d'un large écosystème SQL.

À mesure que votre produit grandit, vous pouvez ajouter des bases spécialisées (une DB vectorielle pour la recherche sémantique, ou un entrepôt columnar pour l'analytique) tout en gardant PostgreSQL comme source de vérité. L'important est de commencer par les charges indispensables aujourd'hui — et de garder la possibilité d'« ajouter un second store » quand les motifs de requête l'exigent.