DynamoDB est-il conforme ACID ?

Oui. DynamoDB prend en charge les transactions ACID via les API TransactWriteItems et TransactGetItems. Elles regroupent jusqu'à 100 actions en une seule opération tout ou rien, avec des garanties d'atomicité, de cohérence, d'isolation et de durabilité à l'intérieur d'une même Région AWS. Les écritures sur un seul élément sont elles aussi atomiques et durables, mais l'ACID multi-éléments passe par les API de transaction.

Ce que veut dire ACID ici

Une transaction DynamoDB applique soit toutes les actions, soit aucune (atomicité), laisse les données dans un état valide (cohérence), est isolée des transactions concurrentes, et est validée durablement dès qu'elle renvoie un succès. Ces garanties valent dans la Région AWS où l'API de transaction a été invoquée.

Les API de transaction

TransactWriteItems — une écriture synchrone et idempotente qui regroupe des actions Put, Update, Delete et ConditionCheck.
TransactGetItems — une lecture atomique et cohérente de plusieurs éléments.

Tu ne peux pas viser deux fois le même élément dans une transaction.

La limite est 100, pas 25

La référence de l'API dit que TransactWriteItems "groups up to 100 action requests" et que "the aggregate size of the items in the transaction cannot exceed 4 MB" (consultée le 2026-07-28). Le chiffre était 25 avant 2022, et ce nombre périmé est encore assez répandu pour valoir une vérification dans l'API plutôt que dans un billet de blog.

Une transaction de 100 actions est acceptée. Une transaction de 101 actions est rejetée :

ValidationException: Member must have length less than or equal to 100

Remarque ce que ce message ne contient pas : le mot « transaction ». C'est une plainte générique sur la longueur d'un tableau : elle ne remontera donc pas dans une recherche de logs sur les erreurs de transaction. Les API batch sont moins pudiques. BatchGetItem avec 101 clés renvoie Too many items requested for the BatchGetItem call, et BatchWriteItem avec 26 renvoie la même phrase avec son propre nom dedans.

Viser deux fois le même élément échoue également, même si chaque action réussirait isolément :

ValidationException: Transaction request cannot include multiple operations on one item

C'est celle qui piège le code construisant la liste d'actions à partir d'une boucle sur des événements entrants sans dédupliquer par clé au préalable.

Les transactions sont aussi facturées double. Écrire 100 éléments de 1 KB de façon transactionnelle consomme 200 unités d'écriture contre 100 pour les mêmes éléments écrits individuellement : l'atomicité a donc un prix même quand rien n'échoue.

Et les tables globales ?

Une transaction n'est ACID que dans la Région où elle a été invoquée. Sur les tables globales utilisant le mode par défaut de cohérence à terme multi-Région (MREC), les écritures transactionnelles ne sont pas répliquées comme un tout — une autre Région peut brièvement observer une transaction partiellement répliquée pendant que les changements se propagent. Les tables globales configurées en cohérence forte multi-Région (MRSC) ne prennent pas du tout en charge les API de transaction.

Aller plus loin

Apprends à modéliser tout ça sans risque dans les transactions DynamoDB, et construis les expressions de condition dont elles ont besoin avec l'Expression Builder. Essaie sur tes propres tables — télécharge DynoTable.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus ; les limites de 100 actions et de 4 MB ont été reconsultées dans la référence de l'API le 2026-07-28.

Les rejets ci-dessus ont été reproduits le 2026-07-28 sur DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) via @aws-sdk/client-dynamodb 3.1095.0. Chaque chaîne citée est la sortie du moteur, telle quelle.