Types de bases de données : modèles, exemples et quand utiliser chacun d’eux

Dans Star Trek : TNG, lorsque quelqu’un a besoin d’une donnée, il n’ouvre pas une console SQL et ne lance pas un cluster MongoDB. Il parle à LCARS, le système de la Fédération à la douce voix de l’infirmière Chapel, qui restitue instantanément des manuels techniques, des archives diplomatiques, des relevés de capteurs et même la recette de l’Earl Grey du capitaine Picard. En 2026, LCARS relève encore de la science-fiction, mais son idée de fond, stocker et restituer des informations de natures radicalement différentes avec l’outil adapté, définit le défi qui se présente à nous : il existe autant de types de bases de données que de types de questions que nous voulons poser à ces données.
Et choisir la mauvaise base de données, c’est comme stocker des fichiers secrets de la CIA dans une feuille de calcul. Le système vous laissera le faire, mais vous en paierez la facture plus tard en performances, évolutivité, maintenance, factures cloud et/ou nuits difficiles face à un serveur qui ne répond pas.
C’est pourquoi ce guide complet passera en revue les principaux types de bases de données, leurs exemples réels et les cas où elles excellent ou s’effondrent.
L’objectif n’est pas de vous vendre la dernière tendance, mais de faire en sorte que, jusqu’à ce que LCARS devienne réalité, vous repartiez avec une connaissance et des critères clairs pour choisir la solution adaptée au défi qui se présente à vous.

Qu’est-ce qu’une base de données

Je déteste les clichés, mais il est vrai que tout voyage commence par un premier pas, et celui-ci est nécessaire pour construire un guide réellement complet.
Une base de données est, essentiellement, un ensemble organisé d’informations persistantes, conçu pour stocker, interroger et modifier les données qui le composent de manière fiable.
Jusqu’ici, c’est la définition de manuel, mais ce qui est intéressant, c’est de ne pas confondre trois éléments que l’on mélange trop souvent dans de nombreuses conversations :

• La base de données proprement dite. Autrement dit, les données organisées selon certaines règles.
• Le DBMS ou système de gestion de bases de données (Database Management System, également SGBD en français). C’est le logiciel qui fait le « sale boulot » nécessaire à son fonctionnement, comme gérer le stockage physique, les requêtes, la concurrence, la sécurité ou les sauvegardes. PostgreSQL, MongoDB ou Oracle Database sont des DBMS.
• Le modèle de données. Ou la théorie sur la manière dont l’information est concrètement organisée, qui peut être relationnelle, documentaire, en graphe, vectorielle… C’est la logique mise en œuvre par le DBMS.

Ou, plus simplement, vu d’en haut :

• Le modèle est le plan de l’architecte.
• Le DBMS est le maçon avec ses outils, qui construit et entretient.
• La base de données est la maison où vit l’information.

Comprendre cela permet de mieux choisir et d’éviter les débats stériles du type : « SQL est-il meilleur que MongoDB ? ».
Cette question mélange un langage, un modèle et un produit en seulement cinq mots. Ainsi, avant de comparer quoi que ce soit ou de décider, chaque concept doit être remis à sa place.
Si nous voulons une vision académique du terme sans maçons ni Star Trek, IBM propose une bonne référence si nous devons revenir davantage aux fondements théoriques. Mais pour ce qui nous intéresse, continuons à dresser le tableau général.

Principaux types de bases de données

Nous rencontrons ici un défi courant : il n’existe pas de taxonomie unique. Selon l’angle qui nous intéresse, il existe plusieurs manières de regrouper les bases de données, par exemple :

• Par le modèle de ces données : relationnel, documentaire, graphes…
• Par architecture : monolithique (centralisée), distribuée, fédérée, etc.
• Par déploiement : on-premise, cloud, managée…
• Par cas d’utilisation : transactionnel, analytique, cache et plus encore.

C’est ce qu’il convient de signaler si l’on veut traiter le sujet avec précision, mais bien sûr, cela n’aide pas beaucoup à prendre des décisions techniques, ce qui nous intéresse ici.
À cette fin, la classification la plus utile est celle par modèle de données, complétée par des familles modernes qui ne rentrent pas dans l’ancienne dichotomie « SQL vs NoSQL ».
Une bonne référence est la classification générale par modèle maintenue par IBM, qui est assez alignée avec celle que nous allons voir, mais ici nous allons aller plus en profondeur que Big Blue afin que vous disposiez d’un guide réellement définitif.
Voici la carte du voyage : bases de données relationnelles, NoSQL sous ses différentes formes (documentaires, clé-valeur, colonnes, graphes), séries temporelles, vectorielles, NewSQL, cloud ou DBaaS et, enfin, entrepôts analytiques et data warehouses.
Commençons donc par la première case en examinant…

1. Bases de données relationnelles

C’est ce qui vient d’abord à l’esprit de tout technicien lorsqu’on lui parle de bases de données, et pour une bonne raison.
Elles nous accompagnent depuis les années soixante-dix, ont été proposées par E. F. Codd chez IBM et restent aujourd’hui le premier choix par défaut pour la plupart des applications.
Elles organisent l’information en tables avec des lignes (enregistrements) et des colonnes (attributs). Chaque table possède généralement une clé primaire qui identifie ses enregistrements et peut également avoir des clés étrangères qui la relient à d’autres tables.
Sur cette structure fondamentale, et jusqu’à ce que nous puissions converser avec LCARS, les requêtes se font avec SQL (Structured Query Language), un langage déclaratif dans lequel nous indiquons au moteur ce que nous voulons et il se charge du comment.
Leur grande vertu est de fournir les fameuses garanties ACID (Atomicity, Consistency, Isolation, Durability). Ou, pour le dire de manière compréhensible, si un virement bancaire débite de l’argent d’un compte et l’ajoute à un autre, soit les deux opérations se produisent, soit aucune ne se produit.
Cela garantit que seule la moitié du processus ne reste jamais exécutée.
Des cas d’utilisation typiques ? Ils sont très nombreux et nous entourent dans notre quotidien de bureau et de café soluble : ERP, CRM, systèmes financiers, inventaires, facturation, applications transactionnelles et, en général, pratiquement tout projet où les données sont bien structurées et où la cohérence est la directive principale à prendre en compte.
Il en existe aussi bien en Open Source que sous licence propriétaire, et des exemples de ce type de base de données sont MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server ou MariaDB.

2. Bases de données NoSQL

NoSQL ne signifie pas dire non à SQL, aussi paradoxal que cela puisse paraître (en fait, de nombreux moteurs NoSQL proposent des langages de requête similaires). Le terme, popularisé en 2009, se comprend mieux comme Not Only SQL.
Autrement dit, une famille de bases de données non relationnelles conçues pour les cas où le modèle tabulaire atteint ses limites.
Et quand cela se produit-il ?

• Lorsque les données n’ont pas de schéma fixe.
• Lorsqu’il faut évoluer horizontalement en répartissant la charge entre de nombreux nœuds.
• Lorsque l’on privilégie la disponibilité et la latence par rapport à la cohérence immédiate, selon le célèbre théorème CAP.

Celui-ci, comme une sorte de principe de Heisenberg, affirme qu’en cas de partition réseau, un système distribué ne peut pas garantir simultanément cohérence et disponibilité.
Pour le rendre un peu plus clair, nous utilisons NoSQL lorsque l’information est massive, change constamment de forme, arrive à toute vitesse et s’adapte mieux lorsqu’elle est répartie entre plusieurs nœuds.
Pour le chaos permanent d’Internet, avec des millions de personnes qui mettent un like à une vidéo sur TikTok (ou à ce qu’elle peut bien contenir), ou avec tout le monde qui regarde des séries sur Netflix en même temps, NoSQL peut enregistrer instantanément ces likes ou, dans le cas de Netflix, répartir les données entre des milliers de serveurs.
Avec une base de données relationnelle traditionnelle sans réplicas, partitionnement, cache ou sharding, l’application pourrait se retrouver bloquée par l’afflux et le conflit entre les données entrantes.
Avec ces prémisses, NoSQL est un domaine vaste qui regroupe des modèles très différents les uns des autres, de sorte que dire « nous utilisons NoSQL » sans rien préciser d’autre revient à dire « je travaille avec des véhicules » sans préciser si nous pilotons des hélicoptères ou des sous-marins.
Pour éviter de tomber dans cette généralité confuse, il convient de bien comprendre la différence entre chaque sous-famille, ainsi que les différences entre SQL et NoSQL lorsqu’il s’agit de choisir.

3. Bases de données documentaires

Le nom vend déjà la mèche : elles stockent des documents, généralement dans des formats structurés comme JSON, BSON ou XML.
Chaque document est autonome, de sorte qu’il contient ses propres champs et sa propre structure (au lieu que tout cela soit déterminé par la base de données) et n’a pas besoin de ressembler à celui d’à côté.
Cela sera idéal lorsque les données ont un schéma variable ou changent fréquemment.
Dans la vie réelle, cela se traduit par des catalogues de produits, des profils utilisateur, des gestionnaires de contenu, des configurations par client ou toute application où ajouter un nouveau champ n’implique pas de réécrire la moitié de la base de données.
Des exemples de ce type de base de données sont MongoDB, Couchbase et RavenDB. Si vous devez exploiter ce dernier en production, d’ailleurs, voici comment superviser RavenDB sans perdre le sommeil.

4. Bases de données clé-valeur

Conceptuellement, ce sont les bases de données les plus simples, car chaque donnée est stockée sous forme de paire clé-valeur, c’est-à-dire comme un dictionnaire géant. Comme ceci :

• La clé identifie la donnée.
• La valeur peut aller d’une chaîne de texte à un blob binaire (une image, un PDF…).

Ici, nous sortons la Ferrari, car le facteur clé est la vitesse brute.
Il n’y a pas de schémas, pas de relations, pas de requêtes complexes. Nous demandons une clé et la base de données nous renvoie sa valeur à vitesse warp 9.
Mais comme rien n’est gratuit dans la vie, le prix à payer est qu’il ne faut pas s’attendre à pouvoir effectuer un join ou une requête analytique, par exemple. D’autres familles existent déjà pour cela ; ici, nous vivons à la vitesse de l’éclair.
Des cas d’utilisation ? Nombreux, lorsque les données et leur usage exigent de la vitesse avant tout, comme les caches applicatifs, les sessions utilisateur, les compteurs en temps réel, les files légères…
Des exemples de ce type de base de données sont Redis, Riak ou Amazon DynamoDB.

5. Bases de données orientées colonnes

Cette étiquette regroupe généralement aussi bien les bases colonnaires analytiques que les magasins wide-column ou à familles de colonnes, même si, en interne, ils ne résolvent pas exactement le même défi.
Quand on les regarde de loin, elles ressemblent à des bases de données relationnelles, mais si l’on met ses lunettes de près, on remarque quelque chose de curieux : elles stockent l’information par colonnes plutôt que par lignes.
Cette différence peut sembler mineure, mais elle change radicalement ce que le moteur peut faire rapidement.
Ainsi, lorsqu’une requête n’a besoin que de quelques colonnes parmi des millions d’enregistrements, la lecture par colonnes évite de charger depuis le disque tout ce qui n’est pas pertinent.
Qu’est-ce que cela signifie en pratique et pour notre objectif ultime de prendre la meilleure décision ? Ces bases de données sont très efficaces pour l’analytique, les agrégations et les grands volumes d’écritures distribuées.
Elles sont ainsi optimales pour faire de l’analytique à grande échelle, stocker et interroger des logs, des événements, de la télémétrie, des données IoT ou des scénarios avec une écriture intensive répartie entre plusieurs nœuds.
Des exemples de ce type de BDD sont, parmi les bases colonnaires analytiques, ClickHouse, et parmi les magasins wide-column, Apache Cassandra, HBase ou ScyllaDB.

6. Bases de données de graphes

Les données relationnelles sont efficaces pour représenter les relations, mais seulement tant que celles-ci restent relativement « monogames » ou avec une polygamie pas trop étendue dans ces relations. Cependant, les choses se compliquent lorsqu’elles sont nombreuses, profondes ou changeantes.
Dans ces cas, les bases de données de graphes entrent en scène.
Elles représentent l’information sous forme de nœuds (entités) et d’arêtes (relations entre ces entités), avec des propriétés dans les deux cas.
L’élément clé est que lorsque nous interrogeons ce type de bases de données, les requêtes parcourent le graphe en suivant les relations, plutôt qu’en parcourant des tables.
Qu’est-ce que cela signifie dans le monde réel ? Qu’elles sont idéales pour les moteurs de recommandation, l’analyse de dépendances, les réseaux sociaux, la modélisation des connaissances, la gestion des identités…
Des exemples de ce type de base de données sont Neo4j, Amazon Neptune ou ArangoDB.

7. Bases de données de séries temporelles

Personne n’échappe au domaine du temps, pas même la gestion IT. C’est pourquoi on y trouve des données dont la nature consiste en une séquence de valeurs associées au temps. Par exemple, la température d’une salle chaque minute, les centaines de cafés par seconde consommés dans le département, les cours de bourse chaque milliseconde…
Sur le papier, nous pourrions stocker tout cela dans une table relationnelle, mais en pratique, nous aurons vite des milliards de points de données dans la plupart des cas.
À ce stade, ce moteur relationnel lève rapidement le drapeau blanc.
Pour cette raison, les bases de séries temporelles sont optimisées pour l’écriture massive, la compression temporelle et les requêtes par fenêtres (comme la dernière minute, la moyenne des trois dernières heures, l’année dernière…).
De ce fait, ce type de base de données est devenu la colonne vertébrale qui soutient la supervision moderne.
Au quotidien, elles sont utilisées pour cette supervision d’infrastructure, l’IoT, la télémétrie industrielle, la planification de capacité, les métriques financières, etc.
Des exemples de ce type de base de données sont InfluxDB, TimescaleDB…

8. Bases de données vectorielles

Si vous n’avez pas touché aux bases de données depuis quelques années, voici la nouveauté qui a le plus changé le paysage, principalement en raison de l’IA omniprésente à laquelle nous ne pouvons plus échapper et qui a multiplié son importance et son utilisation.
Les bases de données vectorielles stockent des embeddings (comme la traduction numérique que l’Intelligence Artificielle fait du monde), des représentations numériques multidimensionnelles de texte, d’images, d’audio ou de tout contenu qu’un modèle d’IA a « compris » (notez bien les guillemets autour du mot).
L’élément clé ici est que nous pouvons effectuer des recherches par similarité sémantique dans ces vecteurs. Ainsi, au lieu de rechercher un mot exact, comme « voiture », elles trouvent des résultats sur « automobile », « véhicule » ou « cabriolet rouge », parce que leurs vecteurs sont proches dans l’espace.
Les cas d’utilisation réels sont les recommandations sémantiques, la Retrieval Augmented Generation (RAG) pour les applications avec LLM, la recherche multimédia, la classification de contenu…
Et des exemples de ce type de base de données sont Pinecone, Milvus, Weaviate…

9. Bases de données NewSQL

Comme c’est souvent le cas en IT, les bases de données nous présentent un dilemme classique.
Les moteurs relationnels traditionnels nous offrent de solides garanties transactionnelles, mais il est difficile de les faire évoluer horizontalement, comme nous l’avons vu. Pendant ce temps, NoSQL évolue bien, mais une fois encore, rien n’est gratuit, et le tribut demandé est que nous renoncions à une partie de ces garanties.
NewSQL tente de résoudre ce dilemme et de nous permettre de faire une omelette sans casser les œufs, de sorte qu’il conserve SQL et l’ACID déjà mentionné, mais les transpose dans une architecture distribuée.
Ces bases de données tentent de réconcilier le meilleur des deux mondes…

• En répartissant ces données entre les nœuds.
• En gérant le consensus avec des algorithmes comme Raft ou Paxos.
• En maintenant l’illusion d’une base de données relationnelle unique.

Leurs cas d’utilisation dans le monde réel sont les systèmes transactionnels distribués, la fintech avec une présence mondiale, le SaaS multirégion…
Des exemples de ces bases de données sont CockroachDB (mon nom préféré), Google Spanner, YugabyteDB…

10. Bases de données cloud et DBaaS

Oui, je sais, plus qu’un modèle de données, il s’agit en réalité d’un modèle de déploiement. Dans ce cas, il convient de distinguer trois niveaux :

• Autogérée dans le cloud. Autrement dit, vous installez PostgreSQL sur une VM AWS ou GCP. Le cloud nous fournit la machine, et nous nous occupons nous-mêmes de tout le reste.
• Managée. Ici, le fournisseur administre le moteur (correctifs, sauvegardes, haute disponibilité…), mais nous continuons à choisir le produit, comme Amazon RDS, Azure SQL Database…
• Database as a Service (DBaaS). Ici, la machine et le moteur relèvent de la responsabilité du fournisseur, qui propose une base de données sous forme d’API. DynamoDB (qui, comme nous l’avons déjà vu, est aussi une base clé-valeur, mais AWS la propose sous ce format), Firestore ou MongoDB Atlas fonctionnent de cette manière.

Les cas d’utilisation sont clairs et apparaissent lorsque nous avons besoin d’une évolutivité rapide, lorsque nous sommes une petite équipe sans administrateurs de bases de données spécialisés, lorsque nous réalisons des déploiements mondiaux, lorsque nous testons des prototypes où nous ne voulons pas nous préoccuper du matériel…
Mais en échange de ce confort, nous assumons bien sûr un risque.
Dans ce cas, la dépendance au fournisseur, des coûts variables comme le paiement à l’usage et, dans certains cas, moins de contrôle sur le réglage fin de l’infrastructure sur laquelle nous travaillons.

11. Data warehouse et bases de données analytiques

Imaginons le cas suivant. Nous devons agréger des millions de lignes de données parce que nous voulons dégager des tendances (OLAP, Online Analytical Processing).
Ici, une base de données transactionnelle, optimisée pour lire et écrire rapidement des enregistrements individuels (OLTP, Online Transaction Processing), n’est pas la meilleure option.
C’est à cela que servent les entrepôts de données (data warehouses) et les bases analytiques, qui sont des moteurs conçus pour répondre à des requêtes complexes sur de longs historiques. Généralement avec un stockage par colonnes (comme nous l’avons vu plus haut) et une compression agressive.
Lorsque notre besoin concerne la Business Intelligence, les rapports, les tableaux de bord exécutifs ou l’analyse historique, cette option entre en jeu.
Exemples : Snowflake, Google BigQuery, Amazon Redshift…

Comparatif des types de bases de données

Le voyage à travers les différents royaumes des bases de données a été long, il convient donc de faire une pause et de récapituler l’essentiel de chacune dans ce tableau (d’ailleurs, à titre de curiosité, vous pouvez consulter la popularité de chaque modèle ici).

Type	Modèle de données	Cas d’utilisation typiques	Avantages	Limites	Exemples
Relationnel	Tables avec relations	ERP, CRM, transactions…	ACID, SQL, écosystème mature	Évolutivité horizontale plus complexe dans les modèles traditionnels, schéma rigide	PostgreSQL, MySQL, Oracle
Documentaire	Documents JSON/BSON	Catalogues, CMS, profils…	Schéma flexible	Requêtes complexes plus coûteuses	MongoDB, Couchbase
Clé-valeur	Paires clé-valeur	Cache, sessions…	Latence minimale	Pas de requêtes complexes	Redis, DynamoDB
Colonnes	Tables par colonnes	Analytique, logs…	Lectures sélectives rapides	Coût d’écriture	Cassandra, HBase
Graphes	Nœuds et arêtes	Fraude, recommandations…	Parcours des relations	Modélisation plus exigeante	Neo4j, Neptune
Séries temporelles	Points temporels	Supervision, IoT…	Compression, fenêtres	Modèle limité hors données temporelles	InfluxDB, TimescaleDB
Vectoriel	Vecteurs d’embeddings	RAG, recherche sémantique…	Similarité, IA	Modèle récent, écosystème en évolution	Pinecone, Milvus, pgvector
NewSQL	Relationnel distribué	SaaS mondial, fintech…	SQL + évolutivité horizontale	Complexité opérationnelle	CockroachDB, Spanner
Cloud / DBaaS	Variable	Toute charge cloud-native…	Moins d’administration	Vendor lock-in, coût variable	RDS, BigQuery, Atlas
Data warehouse	Columnar analytique	BI, reporting…	Requêtes massives efficaces	Pas pour OLTP	Snowflake, Redshift

Comment choisir le bon type de base de données

Comme ce contenu vise à être pratique dans notre quotidien, nous avons déjà vu, pour chaque type de base de données, des exemples réels et des cas d’utilisation courants, ce qui oriente déjà beaucoup au moment de choisir.
Nous allons maintenant approfondir la manière de faire ce choix, et la première chose consiste à confirmer l’intuition que beaucoup auront déjà eue :
Dans la plupart des situations et des organisations, la décision sera composée d’un mélange de types de bases de données. Car nous aurons des besoins très différents au sein d’une même organisation (comme la supervision, le reporting et la gestion des utilisateurs, par exemple), et pour chacun d’eux nous aurons besoin du type de base de données spécialisé qui leur correspond.
Et pour passer de chacun de ces besoins concrets à la famille adaptée, voici le raccourci. Commencez toujours par la question qui décide le plus (à quoi sert la charge ?) et descendez à partir de là.

Étape 1. Quel est l’objectif dominant de cette charge de données ?

• Servir une application (opérationnel, le quotidien, ce que l’on appelle OLTP) → allez à l’Étape 2.
• Dégager des tendances sur de longs historiques (rapports, Business Intelligence, ce que l’on appelle OLAP) → data warehouse ou base colonnaire analytique (Snowflake, BigQuery, Redshift, ClickHouse).
• Ce qui compte, ce sont les relations entre les entités (recommandations, fraude, réseaux, dépendances) → graphes (Neo4j, Neptune).
• Des données qui sont une séquence dans le temps (métriques, télémétrie, supervision) → séries temporelles (InfluxDB, TimescaleDB).
• Recherche par signification, généralement pour l’IA (RAG, similarité sémantique, embeddings) → vectoriel (Pinecone, Milvus, Weaviate, pgvector).

Étape 2. Si elle est opérationnelle, quelle forme ont les données ?

• Tabulaires et bien définies, avec la cohérence comme priorité sacrée :
  • Une évolutivité sur un seul serveur ou une seule région suffit-elle ? → relationnel (PostgreSQL, MySQL).
  • Avez-vous besoin de SQL et de garanties ACID, mais à l’échelle mondiale ? → NewSQL (CockroachDB, Spanner).
• Schéma variable qui change souvent de forme → documentaire (MongoDB, Couchbase).
• Vous demandez uniquement la donnée par sa clé et souhaitez une latence minimale (cache, sessions, compteurs) → clé-valeur (Redis, DynamoDB).
• Écriture massive répartie entre de nombreux nœuds (logs, événements, IoT à grande échelle) → wide-column (Cassandra, ScyllaDB).

Et une décision supplémentaire, indépendante : qui l’exploite ?
Dans la vie réelle, peu importe la famille vers laquelle l’arbre vous a conduit (relationnelle, documentaire ou autre), cette question est indépendante du modèle de données.
Dans le jargon, on parle de décision « orthogonale », ce qui n’est qu’une manière technique de dire que ce sont deux décisions qui ne se chevauchent pas. Quelle que soit la réponse à l’une, l’autre reste ouverte.
Et elle comporte trois niveaux :

• Vous l’exploitez sur une machine virtuelle → autogérée dans le cloud (contrôle maximal, travail maximal).
• Le fournisseur exploite le moteur (correctifs, sauvegardes, haute disponibilité) → managée (Amazon RDS, Azure SQL).
• Le fournisseur exploite tout et vous la fournit comme un service → DBaaS (DynamoDB, Firestore, MongoDB Atlas) : moins d’administration, mais plus de dépendance à ce fournisseur.

Et avant de poursuivre, voici la règle d’or qui clôt l’arbre.
En cas de doute et si vos données sont raisonnablement structurées, commencez par une base relationnelle.
C’est l’option par défaut et celle qui provoque généralement le moins de regrets.
Cela dit, et même si nous l’aurons également déduit de ce qui précède, il faut faire l’avertissement irritant et honnête de toujours.
Il n’existe pas de « meilleure base de données » ou de modèle supérieur aux autres, seulement des options préférables selon notre cas d’utilisation concret.
C’est pourquoi nous pouvons proposer un arbre de décision général et les orientations suivantes, mais pas une checklist définitive ; ce ne serait pas professionnel.

La question des contraintes et des questions supplémentaires lors du choix de la base de données

Dans le monde réel des budgets limités et des compromis constants, choisir une base de données revient à choisir ce qui est optimal pour notre cas, mais surtout à choisir en fonction des contraintes que nous avons.
C’est ainsi dans ce monde matériel. L’arbre nous a donné la famille techniquement idéale, mais avant de l’épouser, il convient de la soumettre à deux filtres. Ce sont des questions qui nous éviteront des déconvenues si nous les posons avant le choix, et non après.

Premier filtre : la famille choisie résiste-t-elle à votre réalité technique ?

L’arbre nous a surtout guidés selon la forme de nos données (si elles sont tabulaires et stables ou métamorphes qui changent de forme chaque semaine), de sorte que ces questions supplémentaires confirmeront que cette branche ne se casse pas avec le reste de votre cas :

• Volume : parlons-nous de gigas, de téras ou de pétas ? La croissance est-elle linéaire, saisonnière ou exponentielle ?
• Modèle de lecture et d’écriture : réalisons-nous beaucoup de petites écritures, beaucoup de lectures, des lectures analytiques massives, un mélange… ?
• Cohérence : avons-nous besoin que chaque lecture voie toujours la dernière donnée, ou pouvons-nous tolérer une cohérence seulement éventuelle ?
• Évolutivité : l’évolutivité verticale nous suffira-t-elle (c’est-à-dire ajouter plus de CPU ou de RAM au prix d’un rein), ou allons-nous nous heurter au mur et devoir recourir à l’évolutivité horizontale (plus de machines ou de nœuds) ?
• Latence : vivons-nous et mourons-nous pour répondre en microsecondes, ou acceptons-nous des secondes ?
• Deuxième filtre : nos contraintes nous permettent-elles de choisir ?

C’est ici que l’option techniquement idéale tombe souvent. Et malheureusement, c’est généralement le filtre qui domine le plus dans le monde réel. Ce filtre prend en compte :

• Coûts : évidemment, car dans la vie, c’est l’Argent qui commande. Nous parlons aussi bien des coûts de licence, de matériel ou de facture cloud que de maintenance. Nous parlons ici du coût total de possession réel (TCO en anglais), pas de celui du marketing.
• Équipe technique : quelqu’un sait-il exploiter Cassandra à trois heures du matin (personne ne lèvera la main même si nous demandons), ou avons-nous seulement des admins PostgreSQL ?
• Disponibilité : tolérons-nous des minutes d’arrêt sans perdre d’activité, ou le SLA indique-t-il 99,99 % et Troie brûle-t-elle à chaque minute ?
• Supervision : l’outil d’exploitation dont nous disposons est-il capable de parler avec le moteur de base de données que nous allons choisir ?
• Législation : existe-t-il des données sensibles que nous ne pouvons pas, par exemple, externaliser dans des solutions situées hors d’Europe en raison du RGPD ou de lois similaires qui nous concernent ?

Évidemment, selon la nature de notre organisation et de notre projet, chaque question aura un poids différent, mais les ignorer se termine généralement par des migrations ultérieures de bases de données en production… Le rêve (cauchemar) de tout gestionnaire IT.

Erreurs courantes lors du choix d’une base de données

Chez Pandora, nous ne sommes plus des enfants. Plus de 20 ans dans la brèche nous contemplent (au cas où l’âge ne serait pas déjà clair avec les références de culture populaire dans ces articles). Et pendant ce temps, nous avons souvent rencontré les mêmes erreurs dans les bases de données choisies pour de nombreuses infrastructures IT avec lesquelles nous avons travaillé.
Les principales sont :

• Choisir par effet de mode et non par cas d’utilisation. Un mal beaucoup trop répandu dans la technologie, où l’éclat de la nouveauté exerce un puissant sortilège. Mais le fait que MongoDB ait triomphé sur Hacker News pendant un temps ne signifie pas que c’est ce dont notre ERP industriel a besoin.
• Utiliser NoSQL pour tout. Des équipes entières ont découvert, à force de douleur et de temps, que de nombreux défis avec des données bien structurées se résolvent mieux avec un PostgreSQL bien conçu.
• Ignorer le coût opérationnel. Car le moteur « gratuit » qui exige trois ingénieurs à temps plein n’est évidemment pas gratuit.
• Ne pas prévoir la croissance. En se rendant compte trop tard que ce qui tient avec cent mille enregistrements peut ne pas tenir avec cent millions.
• Oublier les sauvegardes, la sécurité, la haute disponibilité et la supervision dès le début. Ce ne sont pas des éléments optionnels, mais une partie fondamentale du produit.
• Ne pas tenir compte de l’équipe. Parce que la « meilleure » base de données est, bien souvent, celle que nos équipes peuvent bien exploiter.

Bases de données et supervision

Les bases de données d’une organisation sont sa Bibliothèque d’Alexandrie, et c’est pourquoi il n’existe rien de plus crucial dans l’économie actuelle de l’information et de la connaissance.
C’est aussi pour cela qu’il est important que cette « bibliothèque » ne finisse pas en flammes comme celle de l’histoire.
Ainsi, toute base de données qui soutient des processus critiques doit être supervisée comme le reste des actifs. Et nous devons la traiter comme un organe vital, pas comme une boîte noire.
Connexions actives, requêtes lentes, latence, utilisation du disque, verrous, erreurs ou croissance sont des métriques qu’il convient de garder sous contrôle bien avant que l’utilisateur ne nous prévienne avec ce message si typique et si éclairant : « C’est lent ».
Chaque modèle de base de données que nous avons vu exige en outre une approche différente.

• Dans une base de données relationnelle, vous surveillez les deadlocks (blocages produits par des opérations dans la base de données parce que, par exemple, plusieurs requêtes concurrentes sont présentes et l’une attend qu’une autre libère une donnée) et les index (s’ils sont absents, non utilisés…).
• Dans une base documentaire, la taille des collections et les temps de requête.
• Dans une base clé-valeur, les cache hits (demander une donnée et la trouver rapidement) et les evictions (ce qui est retiré de la mémoire rapide afin de maintenir ce cache ajusté aux éléments importants que nous devons trouver à pleine vitesse).
• Dans une base de séries temporelles, la cardinalité, c’est-à-dire le nombre de combinaisons uniques générées par les données, car si elle devient gigantesque, les performances en souffriront.

Sans supervision, nous pouvons avoir choisi la meilleure base de données, mais celle-ci peut ensuite présenter des performances terribles à cause de l’un des événements cités dans les points précédents. Si cela se produit, il pourrait sembler que nous nous sommes trompés lors de l’implémentation, alors qu’en réalité nous nous sommes trompés dans la gestion.
Dans ce guide, nous avons parcouru le vaste territoire de ce sujet, en donnant des critères pour choisir avec succès et en indiquant sur la carte les champs de mines et les étapes indispensables du voyage.
Et celui-ci a été long, comme celui de la Communauté de l’Anneau, mais il était nécessaire pour qu’il soit réellement complet et utile au quotidien.
Je pense donc qu’il est important de marteler quelques-unes des principales clés et de clarifier les doutes les plus courants.
Allons-y.

Questions fréquentes sur le choix des bases de données

Quels sont les principaux types de bases de données ?

Relationnelles, documentaires, clé-valeur, orientées colonnes, de graphes, de séries temporelles, vectorielles, NewSQL, cloud/DBaaS et bases analytiques (data warehouses).
Les premières familles et les séries temporelles sont les plus établies, tandis que les bases vectorielles et NewSQL sont les plus récentes à se consolider, principalement en raison de l’évolution de la technologie (comme l’IA) et de la nécessité d’adapter la gestion aux données générées.

Quelle est la différence entre SQL et NoSQL ?

SQL est un langage de requête associé au modèle relationnel (tables avec schéma fixe et garanties ACID).
NoSQL, de son côté, regroupe des modèles non relationnels (documents, clé-valeur, colonnes ou graphes) qui privilégient la flexibilité du schéma et l’évolutivité horizontale, généralement au prix d’une certaine cohérence, car la vie est toujours un compromis.
Si nous voulons de la rapidité, le prix que demande généralement le monde réel est une part de précision.

Quelle base de données est la meilleure pour de grands volumes de données ?

Cela dépend du type de charge.

• Pour l’analytique massive, des data warehouses comme Snowflake, BigQuery, Redshift ou ClickHouse.
• Pour l’écriture distribuée et les grands volumes opérationnels, des moteurs colonnaires comme Cassandra ou ScyllaDB.
• Pour les charges transactionnelles mondiales, NewSQL comme CockroachDB ou Spanner.

Quel type de base de données utilise-t-on pour l’IA ?

Impossible d’échapper à l’intelligence artificielle, pour laquelle les bases vectorielles (Pinecone, Milvus, Weaviate…) sont celles qui s’intègrent le mieux aux flux RAG, à la recherche sémantique et aux applications avec LLM.
Cela s’explique par leur capacité à stocker et comparer efficacement les embeddings, comme nous l’avons vu précédemment.
Ces BBDD vectorielles cohabitent généralement avec des bases relationnelles ou documentaires qui conservent les données brutes.

Quelle base de données convient pour la supervision ?

Ici, l’élément clé est les bases de séries temporelles (InfluxDB, TimescaleDB…), car elles sont conçues pour l’écriture massive temporelle et les requêtes par fenêtres sur ce temps.
D’autres types peuvent également stocker des métriques de ce style, mais la réalité est qu’ils paient un tribut trop élevé en stockage et en performances.

Quelle est la différence entre base de données et DBMS ?

La base de données est l’ensemble de données ou d’informations organisées. Pendant ce temps, le DBMS ou SGBD (Database Management System) est le logiciel qui les gère.
Par exemple, PostgreSQL est un DBMS, tandis que les dizaines de BBDD que vous créez dans PostgreSQL sont les bases de données.
Au final, la conclusion à la question que nous nous posions au début a cette réponse que personne n’aime, mais qui est la seule vraie : cela dépend.
Cela dépend de ce dont nous avons besoin, de notre organisation, de la manière dont ses connaissances s’articulent, des contraintes que nous avons en matière d’argent, de technologie, de législation lorsqu’il s’agit de données sensibles que nous ne pouvons peut-être pas stocker off-site…
C’est pourquoi ce que LCARS résout dans la fiction avec une seule voix aimable, nous devons le résoudre dans le monde réel avec une stack hétérogène.
Et bien connaître les types de bases de données disponibles fait la différence entre construire cette stack avec discernement ou à coups de migrations ultérieures douloureuses et regarder le soleil se lever depuis la fenêtre du centre de données.