DynamoDB est-il en mémoire ?

Non. DynamoDB n'est pas une base de données en mémoire — chaque écriture est persistée sur un stockage durable et automatiquement répliquée sur trois zones de disponibilité. Quand tu as besoin de la vitesse de la mémoire, DynamoDB Accelerator (DAX) ajoute un cache en mémoire entièrement managé qui fait passer les lectures à terme de quelques millisecondes à un chiffre aux microsecondes.

Durable par conception

DynamoDB est une base de données opérationnelle durable : les écritures sont stockées sur support durable et répliquées sur trois zones de disponibilité par défaut, ce qui soutient un SLA de disponibilité de 99,99 %. C'est le compromis inverse de celui d'un magasin purement en mémoire, où les données vivent en RAM et où la durabilité est optionnelle.

Il est déjà rapide sans cache

DynamoDB de base délivre des lectures et des écritures en quelques millisecondes à un chiffre, de façon constante et à n'importe quelle échelle, parce que chaque lecture vise directement une clé de partition au lieu de balayer. La plupart des charges de travail n'ont jamais besoin de cache.

Le seul DynamoDB en mémoire, c'est l'émulateur

La confusion commence généralement avec DynamoDB Local, qui a bel et bien un mode en mémoire. Démarre-le et la bannière le dit :

docker run -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -inMemory -sharedDb

Initializing DynamoDB Local with the following configuration:
Port:	8000
InMemory:	true
Version:	3.3.0

Écris un élément, redémarre le conteneur, puis cherche-le à nouveau :

after write:            {"total":{"N":"42"},"pk":{"S":"ORDER#1"}}
tables after restart:   []
read after restart:     ResourceNotFoundException | Cannot do operations on a non-existent table

La table est partie avec lui, pas seulement l'élément. Ce flag appartient à l'émulateur de test. Le service managé n'a aucun réglage équivalent, et aucun mode dans lequel une écriture acquittée ne vivrait qu'en RAM.

DAX : la couche en mémoire

Quand les microsecondes comptent — enchères en temps réel, classements de jeux, pages produit très consultées — DAX est la réponse d'AWS : un cache en mémoire write-through compatible DynamoDB, qui améliore d'un ordre de grandeur les performances des lectures à terme avec des changements de code minimes. Il ne convient ni aux lectures fortement cohérentes ni aux charges de travail intensives en écriture.

Payer les lectures ou ajouter un cache

DAX fait gagner de la latence de lecture sur les clés chaudes ; il ne réduit pas la table sous-jacente et ne change rien à la durabilité des écritures. Chaque PutItem acquitté atterrit toujours sur disque dans trois zones de disponibilité, que DAX soit devant ou non. Sur une table de 10 Go, un Scan fortement cohérent facture environ 2,5 millions d'unités de requête de lecture en on-demand dans us-east-1 — mesure ton propre modèle avec le calculateur de tarifs avant de dimensionner un cluster de cache.

Dans DynoTable : l'aperçu de requête indique Scan ou Query et affiche une estimation de RCU quand les métadonnées de la table le permettent, de quoi voir le coût d'une lecture complète avant de la lancer. Les appels Query ordinaires sur clé de partition n'affichent aucune ligne de RCU. Vois SQL Workbench — aperçu du coût de la requête.

Aller plus loin

Comprends les compromis de cohérence dans le guide sur la cohérence, lis DynamoDB peut-il servir de cache ? pour la question inverse, estime les coûts de lecture avec le calculateur de tarifs, et télécharge DynoTable pour inspecter tes tables.

Références

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

Reproduit le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 sur Node v24.18.0. La bannière et les trois lignes de sortie sont reproduites telles quelles.