Quand utiliser DynamoDB (et quand non)

DynamoDB est une database fantastique pour les charges pour lesquelles elle est faite, et frustrante pour le reste. La question décisive est « est-ce que je connais mes modèles d'accès d'avance, et sont-ils key-based ? » Tu as bon et DynamoDB te donne des lectures en millisecondes à un chiffre à n'importe quelle échelle ; tu as tort et tu te battes pour toujours contre l'absence de joins et de queries ad hoc.

Quand dois-je utiliser DynamoDB ?

Utilise DynamoDB quand tes modèles d'accès sont connus, key-based, et high-volume, et que tu veux une latence prévisible en millisecondes à un chiffre à n'importe quelle échelle avec zéro serveur à gérer. Évite-le pour les queries ad hoc, les joins riches, ou l'analytics sur tout le dataset, et quand les données sont petites avec des formes de query qui changent sans cesse.

• Utilise DynamoDB quand tes modèles d'accès sont connus, key-based, et high-volume — et que tu veux une latence prévisible à n'importe quelle échelle sans serveurs à gérer.
• Évite-le quand tu as besoin de queries ad hoc, de joins riches, ou d'analytics sur tout le dataset, ou quand les données sont petites et que les formes de query changent sans cesse.
• Le trade central : DynamoDB te fait concevoir pour tes queries d'avance ; en retour elle ne ralentit jamais à mesure que tu grandis.
• Ce n'est pas une base relationnelle avec une syntaxe différente — la modéliser comme une est la source de douleur #1.

Les signaux qui favorisent DynamoDB

DynamoDB brille quand la plupart de ceux-ci tiennent :

• Tu connais tes modèles d'accès d'avance. Tu peux lister les queries exactes que l'app fait (« get un user par id », « lister les orders d'un user newest-first ») et elles ne changent pas sur un coup de tête. DynamoDB est modélisé autour de ces queries.
• L'accès est key-based. Tu cherches les items par une partition key connue, pas en scannant pour des combinaisons d'attributs arbitraires.
• L'échelle et la latence prévisible comptent. DynamoDB délivre des performances consistantes en millisecondes à un chiffre que le table tienne mille items ou un milliard.
• Tu veux zéro overhead opérationnel. Pas d'instances, pas de failover, pas de vacuuming — c'est fully managed et scale to zero on-demand.
• Le write throughput est high et spiky. Event logs, télémétrie IoT, état session/cart, leaderboards — charges append-heavy avec une clé claire.

Les signaux contre

Atteins une base relationnelle (ou un moteur search/analytics) à la place quand :

• Tes queries sont ad hoc. Les analystes découpent les données par des colonnes arbitraires, ou les requirements changent chaque semaine. La flexibilité SQL gagne ; DynamoDB aurait besoin d'un nouvel index par pattern.
• Tu as besoin de vrais joins et agrégations sur tout le dataset. Reporting, business intelligence, « sum revenue by region by month » — c'est un job OLAP/relationnel. (La question one-off contre un table live est un cas différent — le SQL Workbench de DynoTable exécute JOIN, GROUP BY et agrégats sur DynamoDB côté client ; c'est la charge BI permanente qui appartient ailleurs.)
• Le dataset est petit et low-traffic. Quelques milliers de lignes sur une admin app calme ne tire aucun bénéfice de l'échelle DynamoDB et perd la commodité SQL.
• Tu ne peux pas encore prédire les modèles d'accès. Produit early-stage encore en train de trouver sa forme ? Un schema relationnel que tu peux re-query librement est plus indulgent jusqu'à ce que les patterns se stabilisent.

Comment DynamoDB se compare aux autres databases

« Dois-je utiliser DynamoDB ou X ? » est généralement la même question sous des habits différents : est-ce que X me laisse reporter la décision de modèles d'accès, et qu'est-ce que je paie pour ça ? DynamoDB est l'option qui refuse de te laisser la reporter. Chaque comparaison ci-dessous tourne sur ce seul trade, pas sur des checklists de features.

Relationnel : PostgreSQL, RDS et Aurora

C'est le vrai fork, et celui que la plupart des équipes ratent. Une base relationnelle te laisse écrire la query après avoir les données. DynamoDB non — le table est façonné par les queries avant qu'un seul item soit écrit.

Choisis relationnel quand les formes de query bougent encore, quand tu as besoin de joins ou d'agrégats sur tout le dataset, ou quand les données sont assez petites pour que l'échelle ne soit pas le problème que tu as. Choisis DynamoDB quand les patterns sont stabilisés et key-based et que tu veux qu'ils coûtent la même chose à un milliard d'items qu'à mille.

RDS et Aurora ne changent pas ce calcul — ce sont des moteurs relationnels managés, donc ils héritent de la flexibilité SQL et de son modèle de scaling. Ce qu'ils changent, c'est la comparaison opérationnelle : avec Aurora Serverless l'argument « pas de serveurs à gérer » pour DynamoDB devient beaucoup plus faible, et la décision retombe proprement sur les modèles d'accès. Aurora scale le compute ; DynamoDB retire le concept.

Document : MongoDB et DocumentDB

Les deux stockent des documents JSON-ish, donc ils ont l'air interchangeables avec DynamoDB de loin. Ils ne le sont pas. MongoDB indexe n'importe quel field et lance des queries ad hoc contre ; DynamoDB te donne la partition key, la sort key, et les indexes que tu as déclarés d'avance.

Ça fait de MongoDB le meilleur fit pour des formes de query évolutives, et de DynamoDB le meilleur fit pour celles connues à high volume. DocumentDB siège du côté AWS de la même ligne — il parle l'API MongoDB, donc traite-le comme « la flexibilité MongoDB, le modèle opérationnel AWS », et compare-le à DynamoDB exactement sur l'axe flexibilité-versus-prévisibilité ci-dessus.

Wide-column : Cassandra

Cassandra est le parent architectural le plus proche de DynamoDB : partition key, clustering key, et la même vérité dure qu'une mauvaise partition key est un bug de design dont tu ne peux pas t'indexer la sortie. Si tu choisis entre eux, les facteurs décisifs sont rarement le data model — c'est qui le fait tourner et comment tu paies. Cassandra tu l'opères (ou tu achètes du managed) ; DynamoDB tu le consommes. Amazon Keyspaces est le middle ground Cassandra managé.

Parce que les modèles sont si proches, le guidance de modeling sur ce site se transfère surtout : le raisonnement single-table design sur partition keys et modèles d'accès s'applique à Cassandra presque ligne pour ligne.

In-memory : Redis

Redis et DynamoDB résolvent des problèmes différents. Redis est memory-first et optimisé pour un accès sub-milliseconde à des données que tu peux te permettre de perdre ou reconstruire ; DynamoDB est durable by default. La réponse production courante est les deux — DynamoDB comme system of record, Redis (ou DAX, le propre cache read-through de DynamoDB) devant les hot keys.

Atteins Redis seul seulement quand les données sont vraiment éphémères : compteurs de rate-limit, sessions short-lived, leaderboards que tu peux recompute.

Search : Elasticsearch et OpenSearch

Search et DynamoDB résolvent aussi des problèmes différents — pour une raison plus nette que Redis : DynamoDB n'a pas de full-text search du tout. Query matche sur l'égalité de clé et un ensemble étroit de conditions de sort key. Un Scan avec un FilterExpression lit chaque item puis en écarte la plupart — c'est une marche de table avec un filter boulonné, pas une search, et tu paies pour les items lus plutôt que pour les items renvoyés. Pas de relevance ranking, pas d'analyzers, pas de fuzzy matching, pas de faceting.

Donc la question n'est jamais « DynamoDB ou un search engine ». C'est « est-ce que cette charge a besoin de search, et si oui, qu'est-ce qui feed l'index ? » La forme standard est les deux : DynamoDB comme system of record, un cluster search à côté, et DynamoDB Streams qui porte chaque changement dans l'index. Ça achète une vraie search et te coûte un second système à faire tourner et un index en cohérence à terme avec le table.

OpenSearch et Elasticsearch sont la même décision. OpenSearch est le fork AWS d'Elasticsearch, split à 7.10 en 2021 sur le changement de licence Elastic, et les deux ont divergé depuis. Aucune de cette dérive ne touche cette question — pour « est-ce que la search doit vivre hors DynamoDB », ils se comportent identiquement. Choisis entre eux sur licensing, hosting et quel service managé tu veux opérer, pas sur quoi que ce soit lié à DynamoDB.

Atteins un search engine comme store primaire seulement quand la search est vraiment le produit — log analytics, un catalogue dont le modèle d'accès principal est free-text. Même alors, la plupart des équipes gardent un store durable derrière, parce qu'un index de search est une vue dérivée que tu dois pouvoir reconstruire.

L'axe coût, que la comparaison de modèles cache

Chaque comparaison ci-dessus porte sur les data models, mais la surprise sur la facture est généralement structurelle : les moteurs relationnels facturent la capacité que tu provisions, DynamoDB facture les opérations que tu effectues. Ça rend DynamoDB bon marché pour les charges spiky et idle et cher pour le scanning soutenu — la même charge peut gagner sur un moteur et perdre lourdement sur l'autre sans aucun changement de code entre eux.

Le multiplicateur que les gens ratent, ce sont les indexes. Sur un moteur relationnel un index en plus coûte du stockage et un peu de latence d'écriture ; sur DynamoDB chaque secondary index est une écriture extra complète des attributs projetés. On a fait l'arithmétique à trois volumes d'écriture dans le guide indexes — un GSI double la facture d'écriture, deux la triplent. Modélise ton vrai mix lecture/écriture dans le calculateur de pricing avant de t'engager d'un côté ou de l'autre.

Compter le coût avant de t'engager

Le pricing DynamoDB suit lectures, écritures et stockage — pas les heures d'instance — donc c'est bon marché pour les charges spiky et serverless et peut être cher pour les scans heavy soutenus. Modélise ton vrai mix lecture/écriture avec le calculateur de pricing DynamoDB avant de t'engager ; une charge qui a l'air d'un fit techniquement devrait aussi tenir sur le coût.

Une fois que tu as décidé que ça fit

Le travail passe au modeling. DynamoDB récompense de concevoir le table autour de tes queries — vois comment modéliser les données dans DynamoDB et single-table design — et explicitement quand ne pas tendre la main vers single-table.

Pièges + étapes suivantes

• Ne modélise pas DynamoDB comme une base relationnelle — des tables normalisés que tu joins au moment de la lecture est l'anti-pattern qu'elle punit le plus durement.
• Ne le choisis pas pour l'analytics — paire-le avec un store analytics (ou exporte vers un) pour le reporting au lieu de scanner.
• Pas sûr des modèles d'accès ? Attends. Adopter DynamoDB avant de connaître tes queries, c'est choisir la seule database qui exige que tu les connaisses.
• Lié : query vs scan montre ce que « l'accès key-based » t'achète vraiment.

Envie d'explorer un table DynamoDB avant de parier ton app dessus ? Télécharge DynoTable et connecte-toi à tes données directement — son SQL Workbench exécute les JOINs ad hoc et agrégats que DynamoDB elle-même ne fera pas.