Comparez les principaux types de bases de données — relationnelle, columnar, document, graphe, vecteur, clé-valeur, séries temporelles, wide-column — avec cas d'usage, compromis et conseils pour bien choisir.
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.).
Différents types de bases de données font des compromis différents :
Ces choix de conception influencent :
Cet article parcourt les principaux types de bases de données et explique, pour chacun :
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.
Commencez par votre charge principale :
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.
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.
Les systèmes relationnels sont généralement interrogés avec SQL (Structured Query Language). SQL est populaire car il est lisible et expressif :
WHERE, ORDER BY).JOIN).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é.
Les bases relationnelles sont connues pour les transactions ACID, qui aident à garder les données correctes :
C'est important quand les erreurs coûtent cher : double facturation d'un client ou perte d'une mise à jour de stock.
Une base relationnelle convient généralement aux données structurées et bien définies et à des flux comme :
La même structure qui rend les bases relationnelles fiables peut aussi ajouter des frictions :
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.
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.
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.
Les requêtes BI effectuent souvent :
SUM, AVG, COUNT et des groupementsLe 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.
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.
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.
Les bases columnar sont adaptées pour :
Si votre priorité est des agrégations rapides sur beaucoup de données, le columnar est souvent le premier type à évaluer.
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.
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.
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.
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 :
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 ».
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.
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).
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.
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).
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.
Ils conviennent à :
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.
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.
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.
Les systèmes wide-column sont conçus pour :
Le plus courant est :
Cela en fait un bon choix pour les données ordonnées dans le temps et les workloads append-heavy.
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é.
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.
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.
Un graphe contient généralement :
Cela rend naturel la représentation de réseaux, hiérarchies et relations plusieurs-à-plusieurs sans tordre votre schéma.
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.
Les graphes sont idéaux pour :
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.
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.
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.
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.
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 :
Ce motif « filtre + similarité » rend la recherche vectorielle pratique pour des datasets réels.
Usages courants :
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).
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.
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.
La plupart des enregistrements séries temporelles combinent :
Cette structure facilite des questions comme « taux d'erreur par service » ou « comparer la latence par région ».
Parce que le volume peut croître rapidement, les TSDB se concentrent souvent sur :
Ces fonctions maintiennent les coûts de stockage et de requêtes prévisibles sans nettoyage manuel constant.
Les TSDB excellent pour des calculs temporels, comme :
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.
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é.
La plupart des entrepôts acceptent les données de deux manières :
Les entrepôts sont optimisés pour l'analytique avec quelques astuces :
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.
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.
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.
Règle simple :
Les bases relationnelles excellent souvent pour l'OLTP ; les systèmes columnar, entrepôts et lakehouses sont courants pour l'OLAP.
Quand une partition réseau survient, vous ne pouvez généralement pas avoir les trois :
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.
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é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.
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.
Notez les 5–10 opérations principales de votre appli ou équipe :
Cela réduit les options bien plus vite qu'une check-list de fonctionnalités.
Raccourci :
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 :
| Cas d'usage principal | Choix souvent adapté | Pourquoi |
|---|---|---|
| Transactions, factures, comptes utilisateurs | Relationnel (SQL) | Contraintes fortes, jointures, cohérence |
| Données applicatives à champs évolutifs | Document | Schéma flexible, JSON natif |
| Cache / état de session en temps réel | Clé-valeur | Recherches rapides par clé |
| Clickstreams / métriques temporelles | Séries temporelles | Forte ingestion + requêtes temporelles |
| Dashboards / grosses agrégations | Columnar | Scans rapides + compression |
| Réseaux sociaux / connaissances | Graphe | Traversées de relations efficaces |
| Recherche sémantique / RAG | Vecteur | Recherche par similarité d'embeddings |
| Données opérationnelles massives | Wide-column | Montée en charge horizontale, requêtes prévisibles |
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.
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.
Un « type de base de données » résume trois choses :
Choisir un type, c'est en pratique choisir des comportements par défaut pour la performance, le coût et la complexité opérationnelle.
Commencez par vos 5–10 requêtes et motifs d'écriture principaux, puis mappez-les vers les forces suivantes :
Les bases relationnelles sont un bon choix par défaut quand vous avez :
Elles deviennent pénibles si le schéma change tout le temps ou si vous avez besoin d'une montée en charge horizontale extrême avec beaucoup de jointures réparties sur des shards.
ACID est une garantie de fiabilité pour des changements multi-étapes :
C'est crucial là où les erreurs coûtent cher (paiements, réservations, mises à jour d'inventaire).
Les bases columnaires sont optimisées quand les requêtes :
SUM, COUNT, , )Une base de documents convient quand :
Attention aux compromis : jointures complexes, duplication des données pour optimiser les lectures, et coût en performance des transactions multi-documents.
Utilisez un magasin clé-valeur quand votre motif d'accès est principalement :
Préparez-vous aux limites : interrogation ad hoc faible, et le support d'index secondaires varie — souvent vous concevez vos propres clés secondaires.
Ils ciblent des besoins différents :
Les systèmes wide-column exigent généralement un modélage guidé par les requêtes et n'offrent pas la même flexibilité de jointures que SQL.
Choisissez un graphe quand vos questions centrales portent sur les relations, par exemple :
Les graphes excellent pour les traversals (parcours relationnels) là où une approche relationnelle nécessiterait de nombreuses jointures. Le compromis : nouveaux paradigmes de modélisation et langages de requête (Cypher, Gremlin, SPARQL).
Une base vectorielle résout la recherche par similarité sur des embeddings (représentations numériques du sens). Cas d'usage typiques :
Elle ne remplace pas la base principale : conservez le « source of truth » (relational/document) et stockez embeddings + index vectoriel dans la DB vectorielle, puis rejoignez les résultats pour obtenir les enregistrements complets et les permissions.
Si vous faites à la fois OLTP et analytique, prévoyez deux systèmes (base opérationnelle + base analytique).
AVGGROUP BYElles sont souvent moins adaptées aux charges OLTP classiques (mises à jour fréquentes et petites lectures par identifiant), que gèrent mieux les row-stores.