DynamoDB est-il rapide ?

Oui. DynamoDB délivre une latence de lecture et d'écriture constante de quelques millisecondes à n'importe quelle échelle. Ajouter DynamoDB Accelerator (DAX), un cache en mémoire, ramène les lectures en cohérence à terme à des microsecondes. Les performances restent stables quand les tables grossissent, parce que les lectures visent directement une clé de partition au lieu de scanner : la latence ne se dégrade donc pas avec le volume de données.

Pourquoi il reste rapide à grande échelle

Un GetItem ou un Query hache la clé de partition et va droit à la bonne partition physique. Il ne scanne jamais la table entière : le temps de réponse est donc à peu près constant, que la table contienne des milliers ou des milliards d'éléments.

Des lectures en microsecondes avec DAX

DAX est un cache en mémoire entièrement managé et compatible DynamoDB, placé devant ta table. Il renvoie les lectures en cohérence à terme en microsecondes — jusqu'à 10 fois mieux que des millisecondes — sans invalidation de cache à gérer. Il ne convient pas aux charges de travail qui exigent des lectures fortement cohérentes.

Le chiffre que tes utilisateurs voient vraiment

Les quelques millisecondes se mesurent à l'endpoint DynamoDB. Ce que ton application vit, c'est cela plus le réseau — et le réseau est en général la plus grosse moitié, et de loin.

Mesuré depuis une machine en Espagne le 2026-07-28, neuf échantillons par Région, médiane de la poignée de main TCP vers chaque endpoint DynamoDB régional. C'est un aller-retour, avant même le premier octet de requête :

Une machine, un FAI, un après-midi : lis ces chiffres comme des ordres de grandeur, pas comme un benchmark. Deux enseignements tiennent en général. Un aller-retour transatlantique vaut plus de dix fois la lecture qu'il transporte : à cette distance, la latence de DynamoDB est une erreur d'arrondi dans la tienne. Et la Région géographiquement la plus proche de la machine n'était pas la plus rapide depuis celle-ci : eu-south-2 se trouve en Espagne et n'a pas fait mieux que Francfort, parce que c'est le routage, pas la distance, qui décide.

En pratique, co-localiser le calcul avec la table bat n'importe quel réglage DynamoDB que tu puisses faire. Une fonction Lambda dans la Région de la table paie une fraction des chiffres ci-dessus ; un portable ou un job de CI sur un autre continent les paie tous, à chaque connexion — et c'est aussi pourquoi la réutilisation des connexions du SDK compte plus qu'il n'y paraît.

Ce qui peut te ralentir

• Les scans et les filtres — lire la table entière est lent et coûteux ; conçois plutôt un accès par clé.
• Les partitions à chaud — quand une clé de partition attire bien plus de trafic que sa part, les requêtes qui la visent sont throttlées alors que la capacité globale de la table va très bien.

C'est une bonne conception de clés, pas plus de matériel, qui garde DynamoDB rapide.

Aller plus loin

Lis query vs scan et évite une partition à chaud. Télécharge DynoTable pour voir quelles lectures s'exécutent en Query et lesquelles en Scan.

Références

• Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
• In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
• What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
• Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Chiffres de latence mesurés le 2026-07-28 depuis une seule machine en Espagne avec curl, neuf requêtes par Région, en rapportant la médiane de time_connect moins time_namelookup sur https://dynamodb.<region>.amazonaws.com. Deux exécutions indépendantes concordaient à 3 ms près.