Is DynamoDB ACID compliant?

Yes. DynamoDB supports ACID transactions through the TransactWriteItems and TransactGetItems APIs. These group up to 100 actions into a single all-or-nothing operation with atomicity, consistency, isolation, and durability guarantees within one AWS Region. Single-item writes are also atomic and durable, but multi-item ACID requires the transaction APIs.

What ACID means here

A DynamoDB transaction either applies every action or none of them (atomicity), leaves the data in a valid state (consistency), is isolated from concurrent transactions, and is durably committed once it returns success. These guarantees hold within the AWS Region where the transaction API was invoked.

The transaction APIs

TransactWriteItems — a synchronous, idempotent write that batches Put, Update, Delete, and ConditionCheck actions.
TransactGetItems — an atomic, consistent read of multiple items.

You cannot target the same item twice in one transaction.

The limit is 100, not 25

The API reference says TransactWriteItems "groups up to 100 action requests" and that "the aggregate size of the items in the transaction cannot exceed 4 MB" (fetched 2026-07-28). The figure was 25 before 2022, and the stale number is still repeated widely enough that it is worth checking against the API rather than a blog post.

A 100-action transaction is accepted. A 101-action one is rejected:

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

Note what that message does not contain: the word "transaction". It is a generic array-length complaint, so it will not turn up in a log search for transaction errors. The batch APIs are less coy about it. BatchGetItem with 101 keys returns Too many items requested for the BatchGetItem call, and BatchWriteItem with 26 returns the same sentence with its own name in it.

Targeting one item twice fails as well, even when each action would succeed alone:

ValidationException: Transaction request cannot include multiple operations on one item

That is the one that catches code building the action list from a loop over incoming events without deduplicating by key first.

Transactions also bill double. Writing 100 items of 1 KB transactionally consumes 200 write units against 100 for the same items written individually, so atomicity has a price even when nothing fails.

What about global tables?

A transaction is ACID only in the Region where it was invoked. On global tables using the default multi-Region eventual consistency (MREC) mode, transactional writes are not replicated as a unit — another Region can briefly observe a partially replicated transaction while changes propagate. Global tables configured for multi-Region strong consistency (MRSC) do not support the transaction APIs at all.

Go deeper

Learn how to model these safely in DynamoDB transactions, and build the condition expressions they need with the Expression Builder. Try it against your own tables — download DynoTable.

References

Last verified 2026-07-13 against the official AWS documentation linked above; the 100-action and 4 MB limits were re-fetched from the API reference on 2026-07-28.

The rejections above were reproduced 2026-07-28 against DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) via @aws-sdk/client-dynamodb 3.1095.0. Every quoted string is verbatim engine output.