Peut-on exécuter DynamoDB en local ?

Oui. AWS livre DynamoDB Local, une version téléchargeable et gratuite de DynamoDB qui tourne sur ta propre machine sous forme d'image Docker, d'exécutable Java ou de dépendance Apache Maven. Elle expose la même API que le service web : tu peux donc développer et tester hors ligne, puis simplement pointer ton code vers AWS.

Trois façons de l'exécuter

Image Docker — le choix le plus courant : un docker run et l'endpoint est en place sur un port local.
Archive téléchargeable — une application Java que tu lances directement (nécessite un JRE).
Dépendance Apache Maven — à intégrer dans des suites de tests JVM.

Pourquoi développer en local

La base de données est autonome sur ton ordinateur : tu économises donc les frais de débit, de stockage et de transfert de données — et tu n'as pas besoin de connexion internet pendant le développement. Quand tu es prêt à déployer, tu retires l'endpoint local du code et il pointe vers le service web DynamoDB.

Attention aux différences

DynamoDB Local émule l'API, mais ce n'est pas le moteur de production — AWS documente des différences de comportement dans ses notes d'utilisation (le débit n'est pas appliqué, par exemple). Traite-le comme un doublon fonctionnel de dev/test, pas comme un modèle de performance.

Trois divergences que nous avons mesurées

Nous gardons un conteneur DynamoDB Local en marche pour reproduire les erreurs citées sur nos pages d'erreur, ce qui veut dire que nous en heurtons les bords régulièrement. Trois valent la peine d'être connues avant de faire confiance à un test local au vert.

Le débit provisionné n'est pas appliqué du tout. Nous avons créé une table à 1 RCU, écrit un élément de 3,5 Ko, puis l'avons relu en lecture fortement cohérente dans une boucle avec les reprises du SDK désactivées (maxAttempts: 1) :

reads=5000 ok=5000 errors=0 elapsed=2.5s rate=1997/s

Cinq mille lectures, aucun throttle, environ 2 000 unités de lecture par seconde soutenues contre une table provisionnée pour une seule. La même boucle contre le service en direct lève une ProvisionedThroughputExceededException à la lecture 49. Un bug de capacité ne peut pas échouer en local.

Une erreur change de nom. Lance deux fois le même INSERT PartiQL et DynamoDB Local répond DuplicateItem avec le message Duplicate primary key exists in table. Le service répond DuplicateItemException avec There was an attempt to insert an item with the same primary key as an item that already exists in the DynamoDB table. Une gestion d'erreurs qui branche sur le nom passe en local et rate en production.

Certaines API sont tout simplement absentes. ExportTableToPointInTime répond :

UnknownOperationException: An unknown operation was requested.

Ce n'est pas l'erreur du service pour le même appel : un chemin de code qui se protège contre PointInTimeRecoveryUnavailableException ne peut donc pas être exercé en local non plus.

Aller plus loin

Le guide DynamoDB Local déroule l'installation pas à pas, et le guide de connexion local & LocalStack montre comment y pointer un GUI — DynoTable se connecte aux endpoints locaux exactement comme il se connecte à AWS. Teste ta première requête avec l'expression builder.

Références

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

Les trois divergences ont été reproduites le 2026-07-28 sur DynamoDB Local 3.3.0 (amazon/dynamodb-local, Corretto 17.0.17) avec @aws-sdk/client-dynamodb 3.1095.0 sur Node v24.18.0. Chaque ligne de sortie ci-dessus est celle du moteur, non retouchée.