DynamoDB è conforme ad ACID?

Sì. DynamoDB supporta transazioni ACID attraverso le API TransactWriteItems e TransactGetItems. Queste raggruppano fino a 100 azioni in un'unica operazione tutto-o-niente con garanzie di atomicità, coerenza, isolamento e durabilità all'interno di una singola regione AWS. Anche le scritture su un singolo Item sono atomiche e durevoli, ma l'ACID su più Item richiede le API di transazione.

Cosa significa ACID qui

Una transazione DynamoDB applica tutte le azioni o nessuna (atomicità), lascia i dati in uno stato valido (coerenza), è isolata dalle transazioni concorrenti ed è confermata in modo durevole una volta che restituisce successo. Queste garanzie valgono all'interno della regione AWS in cui è stata invocata l'API di transazione.

Le API di transazione

TransactWriteItems — una scrittura sincrona e idempotente che raggruppa azioni Put, Update, Delete e ConditionCheck.
TransactGetItems — una lettura atomica e coerente di più Item.

Non puoi puntare due volte allo stesso Item nella stessa transazione.

Il limite è 100, non 25

Il riferimento dell'API dice che TransactWriteItems "groups up to 100 action requests" e che "the aggregate size of the items in the transaction cannot exceed 4 MB" (recuperato il 2026-07-28). Prima del 2022 la cifra era 25, e il numero obsoleto viene ancora ripetuto abbastanza spesso da rendere sensato verificarlo sull'API invece che su un post di blog.

Una transazione da 100 azioni viene accettata. Una da 101 viene rifiutata:

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

Nota cosa quel messaggio non contiene: la parola «transaction». È una generica lamentela sulla lunghezza di un array, quindi non salterà fuori in una ricerca nei log degli errori di transazione. Le API batch sono meno reticenti al riguardo. BatchGetItem con 101 chiavi restituisce Too many items requested for the BatchGetItem call, e BatchWriteItem con 26 restituisce la stessa frase con il proprio nome dentro.

Anche puntare due volte allo stesso Item fallisce, pure quando ciascuna azione da sola andrebbe a buon fine:

ValidationException: Transaction request cannot include multiple operations on one item

È quello che coglie in fallo il codice che costruisce l'elenco di azioni con un loop sugli eventi in arrivo senza deduplicare prima per chiave.

Le transazioni fatturano anche il doppio. Scrivere 100 Item da 1 KB in modo transazionale consuma 200 unità di scrittura contro le 100 degli stessi Item scritti singolarmente, quindi l'atomicità ha un prezzo anche quando non fallisce nulla.

E le tabelle globali?

Una transazione è ACID solo nella regione in cui è stata invocata. Sulle tabelle globali che usano la modalità predefinita multi-Region eventual consistency (MREC), le scritture transazionali non vengono replicate come un'unica unità — un'altra regione può osservare per un attimo una transazione replicata parzialmente mentre le modifiche si propagano. Le tabelle globali configurate per la multi-Region strong consistency (MRSC) non supportano affatto le API di transazione.

Approfondisci

Impara a modellarle in sicurezza in transazioni DynamoDB, e costruisci le condition expression di cui hanno bisogno con l'Expression Builder. Provalo sulle tue tabelle — scarica DynoTable.

Riferimenti

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra; i limiti di 100 azioni e 4 MB sono stati recuperati di nuovo dal riferimento dell'API il 2026-07-28.

I rifiuti qui sopra sono stati riprodotti il 2026-07-28 su DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) tramite @aws-sdk/client-dynamodb 3.1095.0. Ogni stringa citata è output del motore alla lettera.