Guide pratique pour choisir une base de données selon les chemins de lecture/écriture, la latence, la consistance et les besoins de croissance — afin d’éviter que les tendances n’engendrent une dette technique évitable.
Choisir une base de données parce qu’elle est « populaire » revient à acheter un véhicule dont tout le monde parle — sans vérifier si vous avez besoin d’un scooter, d’un pick-up ou d’un bus. Les tendances reflètent ce qui a fonctionné pour le produit, la taille d’équipe, le budget et la tolérance au risque d’une autre équipe. Votre base doit correspondre à votre charge de travail : ce que votre application fait réellement toute la journée.
Une charge de travail, c’est le comportement réel de votre système en production :
Ces comportements sont vos modèles d'accès — les façons répétables dont votre appli touche les données. Si vous pouvez décrire clairement ces modèles, le choix de la base devient beaucoup moins mystérieux.
Une solution unique convient rarement à tout. Beaucoup de systèmes réussis utilisent une approche hybride : une base optimisée pour les transactions, une autre pour l’analytique, et parfois un moteur dédié pour la recherche ou un cache. Ce n’est pas une « complexité inutile » ; c’est reconnaître que des modèles d’accès différents bénéficient de moteurs de stockage et de requête différents.
Avant de comparer « SQL vs NoSQL » ou de courir après la dernière mode, notez vos 5–10 lectures et écritures principales. Commencez par ça ; tout le reste n’est que détail.
Un modèle d'accès décrit pratiquement comment votre application manipule les données au quotidien : ce qu’elle lit, ce qu’elle écrit, à quelle fréquence, à quelle vitesse et en quelles formes. Il s’agit moins de ce que vos données sont ("commandes" ou "utilisateurs") et plus de ce que vous faites avec elles ("récupérer la commande par ID 10 000 fois par minute" ou "scanner toutes les commandes du mois dernier pour générer un rapport").
La plupart des trafics de lecture se rangent dans quelques catégories reconnaissables :
Un fil d’actualité social est un bon exemple de formes mixtes : recherches par point pour les profils, lectures par plage pour les « derniers posts », et agrégations pour des compteurs.
Les modèles d’écriture comptent tout autant :
Les logs sont souvent « orientés écriture et append-only » (beaucoup d’inserts, peu de mises à jour). Les commandes sont généralement « écrire puis mettre à jour » (création, puis changements d’état).
Beaucoup de produits veulent tout en même temps : lectures rapides par point pour l’application, requêtes complexes pour le support client, et grands scans pour l’analytique. Une seule base peut gérer certains mélanges correctement, mais certaines combinaisons s’entrechoquent — par exemple, des scans analytiques lourds peuvent ralentir de petites lectures sensibles à la latence qui servent le checkout ou un fil d’actualité.
Quand vous pouvez nommer clairement vos modèles d’accès, vous pouvez évaluer les bases sur un comportement réel plutôt que sur la popularité.
Avant de comparer des marques de bases de données, nommez la charge que vous servez réellement. La plupart des produits ne sont pas « une seule charge » — ce sont quelques charges distinctes qui coexistent (et parfois se concurrencent). Bien classifier cela tôt évite de forcer une base dans un rôle pour lequel elle n’a pas été optimisée.
L’OLTP est le rythme quotidien de la plupart des applis : beaucoup de petites lectures/écritures, beaucoup d’utilisateurs concurrents, et des requêtes qui doivent se terminer rapidement.
Pensez : « mettre à jour un panier », « créer une commande », « changer une adresse », « vérifier un stock ». Ces opérations sont courtes, ciblées et sensibles à la correction. Si un paiement est capturé, il ne doit pas disparaître ; si un siège est réservé, deux personnes ne doivent pas obtenir le même siège.
L’OLTP vous pousse généralement vers des systèmes qui gèrent bien la concurrence et offrent des garanties claires sur les transactions et l’intégrité des données.
L’analytique change la forme du travail : moins de requêtes, mais chacune touche beaucoup plus de données.
Pensez : « chiffre d’affaires par région le trimestre dernier », « conversion par canal », « meilleurs produits par catégorie », « tendance des utilisateurs actifs quotidiens ». Ces requêtes scannent souvent beaucoup de lignes, groupent, agrègent et trient. Les attentes de latence peuvent être plus souples (des secondes peuvent suffire), mais le coût des scans lourds compte — surtout si les tableaux de bord tournent toute la journée.
Si vous essayez d’exécuter des scans OLAP sur le même système qui gère le checkout, souvent l’un souffrira.
Les séries temporelles et les logs sont généralement orientés append : de nouveaux événements arrivent constamment et on interroge surtout par plages temporelles.
Pensez : métriques, clickstreams, télémétrie d’appareils, logs d’audit. Besoins courants : politiques de rétention (supprimer/expirer les anciennes données), rollups (conserver les événements bruts 7 jours, des agrégats 12 mois) et écritures rapides lors de pics.
Cette charge porte moins sur les jointures complexes et plus sur l’ingestion efficace de beaucoup d’enregistrements horodatés et la prévisibilité du stockage dans le temps.
La recherche n’est pas seulement « trouver des lignes ». C’est l’appariement textuel, le classement par pertinence, les correspondances partielles et le filtrage convivial pour l’utilisateur.
Pensez : recherche de produits par mot-clé, trouver des tickets par phrase, filtrer par facettes (marque, fourchette de prix, couleur), tri par « meilleure correspondance ». Ces fonctionnalités requièrent souvent des index et capacités de requête spécialisées que les bases généralistes peuvent approcher — mais rarement maîtriser.
Si la recherche est une fonctionnalité centrale, traitez-la comme une charge dédiée dès le départ, pas comme un « on ajoutera ça plus tard ».
La performance n’est pas un seul chiffre. Deux bases peuvent être « rapides », mais donner des impressions très différentes aux utilisateurs et aux opérateurs. Pour bien choisir, séparez ce que les humains ressentent (latence) de ce que le système doit soutenir (débit), puis testez vos hypothèses avec des pics.
Latence : combien de temps prend une requête individuelle — « appuyer sur le bouton, obtenir le résultat ». Les utilisateurs ressentent la latence.
Débit : combien de requêtes par seconde le système peut traiter en total.
Une base peut obtenir un débit élevé en batchant, mais avoir un délai perceptible par requête. Une autre peut optimiser les lectures rapides par point, mais peiner quand beaucoup d’écritures arrivent simultanément.
La latence moyenne masque les douleurs. Si 99 requêtes finissent en 50 ms et qu’une prend 2 s, la moyenne semble correcte — mais ce 1% crée le moment où « l’app est lente ». C’est la signification de la latence P99 : le temps nécessaire pour les 1% les plus lents. Pour les fonctionnalités côté utilisateur (checkout, login, recherche), le P99 décide souvent si la conception de la base paraît fiable.
La plupart des systèmes ne tombent pas en arrêt sur la charge moyenne, mais pendant les pics : un email marketing, une actualité majeure, le jour de paie, la clôture de fin de mois.
Les pics changent la conversation :
La mise en cache peut réduire l’apparence d’une charge lecture-lourde — jusqu’à un miss ou une purge de cache.
Si la plupart des lectures touchent le cache, votre base sert principalement les écritures et quelques lectures coûteuses. Cela favorise des choix différents que si chaque lecture atteignait la base. Prévoyez les événements de « cold cache » et la latence en queue, pas seulement le chemin heureux.
Choisir une base n’est pas qu’une question de vitesse. Il faut aussi définir ce qui peut être toléré comme erreur, quelle indisponibilité est acceptable, et où se trouvent vos utilisateurs.
Commencez par identifier les données qui doivent toujours être correctes. Paiements, soldes de compte et comptes de stock en sont des exemples classiques. Si un client est facturé deux fois ou si vous vendez plus d’articles que vous n’en avez, le « coût » n’est pas seulement une application plus lente — ce sont des remboursements, des tickets support et une perte de confiance.
Pour ces parties, vous voulez généralement des garanties fortes : les écritures doivent être confirmées avant d’être considérées comme terminées, et les lecteurs ne doivent pas voir d’états partiellement écrits. Le compromis est que la correction forte réduit souvent la flexibilité : certaines stratégies de montée en charge deviennent plus difficiles, et les écritures multi-régions peuvent ralentir.
Ensuite, décidez ce qui se passe si la base est indisponible 5 minutes.
Si l’indisponibilité signifie « les commandes s’arrêtent et le chiffre d’affaires s’arrête », vous avez besoin d’une disponibilité plus élevée : basculement automatique, bonnes sauvegardes et procédures de maintenance sans arrêt de l’appli. Si l’indisponibilité signifie « les tableaux de bord internes sont retardés », vous pouvez accepter une configuration plus simple.
Une disponibilité plus élevée augmente typiquement le coût et la complexité opérationnelle (plus de réplicas, plus de monitoring, des mises à jour plus prudentes). L’important est d’aligner cet investissement sur l’impact business.
Si vos utilisateurs sont majoritairement dans une région, garder les données au même endroit peut être moins coûteux et plus rapide. Si vous avez des utilisateurs sur plusieurs continents — ou des exigences réglementaires sur la localisation des données — vous devrez peut-être répliquer multi-régions.
Les designs multi-régions améliorent l’expérience utilisateur et la résilience, mais imposent des choix délicats : autorisez-vous des lectures légèrement obsolètes, ou acceptez-vous des écritures plus lentes pour garder tout parfaitement synchronisé ? La bonne réponse dépend de ce que votre workload peut tolérer.
La plupart des « débats sur les bases de données » sont en réalité des arguments sur la forme des requêtes. Si vous savez quelles questions votre appli doit poser — jointures, agrégations, filtres, fenêtres temporelles — vous pouvez souvent restreindre rapidement les options.
Un modèle relationnel brille quand vous avez besoin de filtres flexibles et de jointures entre entités (clients → commandes → articles), surtout si les exigences évoluent. Si votre produit a besoin de reporting ad hoc (« montrer tous les clients qui ont acheté X et aussi retourné Y »), le SQL et les jointures restent souvent plus simples à long terme.
Si vos requêtes sont prévisibles et majoritairement par clé primaire (« obtenir le profil par user_id »), un modèle document ou clé-valeur peut bien fonctionner — en stockant souvent les données déjà groupées comme vous les lisez. Le compromis est que vous pouvez dupliquer des données pour éviter les jointures, ce qui complexifie les écritures et les mises à jour.
Les index permettent de dire à une base « voici mes modèles d’accès ». Une requête qui paraît correcte dans une maquette peut devenir lente si elle filtre ou trie sur des champs non indexés.
Règle utile : tout filtre, tri ou clé de jointure fréquent doit avoir un plan d’index. Mais les index ont un coût : stockage et alourdissement des écritures.
Les promesses d’"écritures rapides" négligent souvent l’amplification d’écriture — le travail supplémentaire créé par des index secondaires, la compaction, la réplication ou la mise à jour de plusieurs copies de données dénormalisées. Un design qui optimise les lectures en ajoutant des index ou en dupliquant des documents peut transformer silencieusement une charge d’écriture élevée en goulot.
« Sans schéma » ne signifie pas « sans structure ». Les schémas flexibles accélèrent l’itération initiale, mais sans conventions ils produisent des champs incohérents, des requêtes difficiles à déboguer et des migrations coûteuses plus tard. Quand vous attendez plusieurs équipes, beaucoup de fonctionnalités ou de longues périodes de rétention, un schéma plus strict et des contraintes claires réduisent souvent le coût total — même si cela semble ralentir au départ.
Choisir une base parce qu’elle est populaire se retourne souvent contre vous dans les parties peu glamours de la propriété : la faire tourner, la sécuriser et payer la facture mensuelle. Deux bases peuvent répondre aux mêmes besoins fonctionnels et avoir des efforts opérationnels et un coût total très différents.
Demandez dès le départ qui gérera le système à 2 h du matin. Sauvegardes, restauration point-in-time, upgrades, patching, drills de basculement et monitoring ne sont pas des tâches « pour plus tard » — elles façonnent vos risques et votre staffing.
Les services managés réduisent le toil, mais ne l’éliminent pas. Certains systèmes demandent une compaction régulière, un tuning fin ou une expertise approfondie pour éviter les ralentissements. D’autres rendent les changements de schéma douloureux ou exigent des playbooks de migration spéciaux. Si votre équipe est petite, une base plus facile à opérer peut surpasser une option « parfaite » sur le papier.
Les coûts de base de données viennent généralement de :
Un modèle d’accès lourd en écritures et indexes secondaires peut multiplier l’I/O et le stockage même pour un petit jeu de données.
Langages de requête propriétaires, fonctionnalités de consistance uniques ou « magique » serverless accélèrent la livraison — mais peuvent limiter les mouvements futurs. Vérifiez si vous pouvez exporter les données, exécuter localement pour les tests, ou changer de fournisseur sans réécrire l’application.
Au minimum, confirmez le chiffrement en transit/au repos, les options de gestion des clés, l’audit, les contrôles d’accès et les politiques de rétention. Les besoins de conformité font souvent la différence entre « ça marche » et « acceptable », indépendamment de la mode.
Une fois que vous avez décrit vos modèles d’accès (ce que vous lisez, ce que vous écrivez, à quelle fréquence et sous quels pics), la famille de base « adéquate » devient souvent évidente. L’objectif n’est pas de choisir l’outil le plus populaire, mais le système le plus simple qui reste correct sous votre charge.
Choisissez une base relationnelle quand vous avez besoin d’une forte consistance, de relations claires et de transactions fiables : commandes, paiements, stocks, permissions, planification. Si vous interrogez fréquemment plusieurs entités (« clients avec factures impayées dans les 30 derniers jours ») ou devez faire respecter des contraintes (emails uniques, clés étrangères), le SQL réduit souvent la complexité applicative.
Heuristique courante : si votre équipe est sur le point de réimplémenter des jointures, contraintes et transactions dans le code, vous voulez probablement une base relationnelle.
Une base documentaire convient quand vous lisez/écrivez surtout des objets complets qui varient en structure : profils utilisateur, pages de contenu, catalogues produits avec champs optionnels, ou réglages. Si votre requête typique est « récupérer le profil par user_id » et mettre à jour des parties, les documents gardent souvent les données nécessaires ensemble.
Soyez prudent si vos requêtes deviennent très relationnelles (beaucoup de requêtes multi-document) ou si vous avez besoin de garanties transactionnelles multi-entités.
Les systèmes clé-valeur excellent pour le caching, les sessions, les limites de débit, les feature flags et l’état de courte durée où le modèle d’accès est « get/set par clé » et où la latence compte. Ils sont souvent complémentaires, pas le système de vérité principal.
Si vous stockez des données business durables, demandez-vous ce qui se passe lors d’évictions, redémarrages ou délais de réplication.
Pour l’analytique — tableaux de bord, cohortes, rollups de revenu, group-by sur l’historique — les systèmes columnaires/entrepôts gagnent car ils sont optimisés pour scanner et agréger beaucoup de lignes efficacement.
Partage pratique : gardez les écritures OLTP dans votre base principale et alimentez un entrepôt pour le reporting. Cela évite de ralentir les requêtes client-facing par des charges BI.
Beaucoup de produits réussis n’« en choisissent » pas une seule. Ils associent chaque modèle d’accès au stockage le plus simple qui le sert bien, même si cela implique 2–3 bases côte à côte.
Une boutique en ligne a souvent trois charges très différentes :
Le produit semble unifié, mais le stockage est spécialisé par modèle d’accès.
Un SaaS B2B peut stocker les entités cœur (projets, factures, tickets) dans une base transactionnelle, tout en ayant besoin :
Les plateformes IoT ingèrent des rafales de télémétrie, puis les relisent pour des tableaux de bord temporels.
Séparation fréquente : un store d’ingestion rapide pour les données récentes, un stockage long terme moins cher pour la rétention, et un moteur analytique pour les agrégats.
Le message clé : différentes composantes peuvent — et devraient souvent — utiliser des bases différentes quand leurs modèles d’accès divergent.
Un mauvais appariement se manifeste souvent par une accumulation de « petites » solutions bricolées. Si l’équipe passe plus de temps à se battre avec la base qu’à construire les fonctionnalités produit, prenez garde — c’est souvent un problème de modèle d’accès, pas de tuning.
Quelques signes récurrents :
Si la base exige des efforts héroïques pour supporter des opérations normales, la famille de base et le workload ne correspondent probablement pas.
Choisir une base à la mode peut vous enfermer dans des coûts à long terme :
La facture arrive quand l’échelle ou les exigences changent et la seule vraie solution est souvent une re‑platformation douloureuse.
Vous n’avez pas besoin d’une observabilité parfaite, mais de quelques signaux :
Écrivez les principaux modèles d’accès (lectures/écritures, requêtes clés, débits de pointe), les hypothèses sur le volume de données et les « non‑négociables » (consistance, disponibilité, contraintes de région). Ajoutez des liens vers des tableaux de bord et des exemples des pires requêtes. Ce court enregistrement accélère les choix futurs — et clarifie quand une base ne correspond plus à la réalité.
Choisir une base devient plus simple si vous le traitez comme une collecte d’exigences, pas un concours de popularité. Utilisez cette checklist pour transformer un vague « il faut que ça scale » en entrées concrètes à comparer.
Répondez d’abord en clair, puis ajoutez des chiffres :
Faites une page avec les critères en lignes et les candidats en colonnes. Marquez chaque critère comme must-have ou nice-to-have, puis notez chaque base (ex. 0–2).
Incluez au moins : adéquation requête, approche de montée en charge, besoins de consistance, effort opérationnel, écosystème/outillage, et prévisibilité du coût.
Testez avec des données représentatives et des requêtes réelles, pas des exemples toy. Recréez les « top queries » et un pattern d’écritures réaliste (pics et backfills inclus).
Si vous itérez vite sur des idées produit, un environnement de type « vibe-coding » comme Koder.ai peut vous aider à monter une appli fonctionnelle et valider tôt les modèles d’accès : générez un frontend React avec un backend Go + PostgreSQL, modélisez quelques endpoints réels et mesurez comment vos « top 5 queries » se comportent avant de vous engager sur une architecture longue durée. La possibilité d’exporter le code source et de garder le contrôle du schéma et des migrations aide aussi à éviter de se retrouver coincé.
Écrivez ce que signifie « passer » à l’avance : cibles de latence, taux d’erreur acceptables, étapes opérationnelles requises (sauvegardes, changements de schéma) et coût mensuel estimé à l’usage attendu. Si un candidat ne satisfait pas un must-have dans le PoC, éliminez‑le tôt.
Préparer l’avenir ne signifie pas choisir la base la plus « scalable » dès le jour 1. Il s’agit de choix délibérés qui vous laissent de la souplesse quand vos modèles d’accès changent.
Si votre workload est majoritairement transactionnel avec des requêtes simples, une base relationnelle est souvent le chemin le plus rapide vers un produit fiable. L’objectif est de livrer avec confiance : performance prévisible, garanties de correction et outils familiers à votre équipe.
« Préparer l’avenir » ici signifie éviter des engagements irréversibles tôt — par exemple adopter un store spécialisé avant d’avoir prouvé que ses compromis valent le coût.
Construisez une couche d’accès aux données explicite (ou une frontière de service) pour que le reste de l’appli ne dépende pas des particularités de la base. Centralisez la logique de requête, définissez des contrats (entrées/sorties) et traitez les changements de schéma comme partie intégrante du développement.
Habitudes pratiques :
Beaucoup de produits finissent par avoir deux voies : OLTP pour les transactions quotidiennes et analytique pour le reporting, les expérimentations ou les agrégats lourds. Séparez quand les requêtes analytiques commencent à nuire à la latence de production, ou quand vous avez besoin de rétention/partitionnement différent.
Pour les garder alignés, standardisez les définitions d’événement/donnée, automatisez les pipelines et réconciliez les totaux (ex. ventes journalières) entre systèmes pour éviter que la « vérité » ne se fragmente.
Si vous voulez une étape concrète, préparez un modèle de plan de migration léger que votre équipe pourra réutiliser : /blog/database-migration-checklist.
Un modèle d'accès est la façon répétable dont votre application manipule les données en production : ce qu’elle lit/écrit, à quelle fréquence, à quelle vitesse et sous quelles formes de requêtes (recherches par clé, lectures en plage, jointures, agrégations, fenêtres temporelles, etc.). C’est plus exploitable que de dire « on a des utilisateurs et des commandes », car cela mappe directement aux index, au schéma et au choix de la base de données.
Parce que « populaire » reflète les contraintes d’autres équipes, pas les vôtres. Une même base peut être excellente pour un type de charge (par ex. OLTP) et inadaptée pour un autre (par ex. analyses lourdes). Commencez par lister vos 5–10 lectures/écritures principales, puis évaluez les bases en fonction de ces comportements plutôt que de la notoriété.
Notez :
Cela devient votre document d’exigences pour comparer les options.
OLTP correspond aux opérations quotidiennes : beaucoup de petites lectures/écritures concurrentes, sensibles à la correction (panier, validation de commande, mise à jour d’adresse). Les transactions et contraintes comptent.
OLAP/analytique correspond à des requêtes plus rares mais qui parcourent beaucoup de données (scans, groupements, tableaux de bord) où une latence de quelques secondes peut être acceptable. Faire cohabiter OLTP et OLAP sur le même système fait souvent souffrir les requêtes utilisateur.
Regardez les percentiles (p95/p99), pas les moyennes. Si le 1% le plus lent prend des secondes, les utilisateurs percevront l’application comme peu fiable même si la moyenne est bonne.
Astuce pratique : suivez p95/p99 pour les points critiques (connexion, paiement, recherche) et corrélez les pics avec les métriques de la base (verrous, latence de réplication, saturation I/O).
Souvent quand les besoins divergent :
Utiliser des stockages spécialisés peut être globalement plus simple que de forcer une seule base à tout faire avec des contournements.
La mise en cache peut faire paraître la base « surtout écriture plus quelques lectures coûteuses ». Cela change les priorités :
Un cache peut masquer des problèmes temporairement, mais aussi créer un effondrement si les misses submergent la base.
La correction forte signifie garantir l’intégrité des écritures et la visibilité des mises à jour (pas d’états « à moitié écrits »). Crucial pour paiements, soldes, inventaires et réservations.
Les compromis :
Définissez clairement quelles données sont « jamais erronées » vs celles tolérant de la staleness.
L’indexation est le contrat de performance entre votre workload et la base. Préparez des index pour les filtres fréquents (WHERE), les tris (ORDER BY), les clés de jointure et les requêtes par plage temporelle.
Attention : les index augmentent le stockage et alourdissent les écritures (amplification d’écriture). Indexez ce que vous faites réellement souvent, pas tout et n’importe quoi.
Considérez un PoC comme une répétition de production :
Si un candidat ne satisfait pas une exigence must-have pendant le PoC, éliminez-le tôt.
