DynamoDB consistency models and ACID properties
DynamoDB is often described as an eventually consistent store, which is only half the picture: it offers a choice of read consistency per request, and full ACID transactions across items and tables. What it does not offer is one setting that makes everything strongly consistent for free — each guarantee has a price in latency, availability or capacity.
Read consistency
Section titled “Read consistency”Eventually consistent reads are the default. They give the best read performance and availability, may not reflect a write that has just completed, and typically converge within a second.
Strongly consistent reads must be requested explicitly (ConsistentRead: true).
They return a result reflecting every write that received a successful response before
the read began. They cost more latency, are less available during network delays or an
Availability Zone problem, and consume twice the read capacity of an eventually
consistent read of the same item.
Global secondary indexes are always eventually consistent, whatever the read setting — strongly consistent reads are only available against the base table and local secondary indexes.
ACID properties
Section titled “ACID properties”DynamoDB supports ACID transactions through TransactWriteItems and TransactGetItems.
- Atomicity — every action in the transaction succeeds, or none does.
- Consistency — a single-item write is always consistent; consistency across several items is what a transaction provides.
- Isolation — transactions are serializable with respect to single-item operations
and to other transactions. Against
BatchGetItem,QueryandScanthe isolation level is read-committed for the operation as a whole. - Durability — a committed write is replicated synchronously across three Availability Zones in the Region before the call returns.
Transaction limits
Section titled “Transaction limits”- Up to 100 actions against up to 100 distinct items, in one or more tables in the same account and Region.
- 4 MB aggregate size across the items in the transaction.
- An item may appear only once in a transaction.
- Transactions cannot be performed through an index.
Each item in a transaction is read or written twice underneath — once to prepare and once to commit — so a transaction consumes twice the capacity of the equivalent non-transactional operations, and consumes it even when the transaction is cancelled.
Splitting a transaction that did not need splitting is a real correctness risk: two smaller transactions are not equivalent to one larger one, because a failure between them leaves the data in a state neither transaction intended. Split only where the application genuinely does not need the two halves to succeed or fail together.
Consistency across Regions
Section titled “Consistency across Regions”Global tables run in one of two consistency modes, chosen at creation and not changeable afterwards.
Multi-Region eventual consistency (MREC) is the default. Writes are replicated asynchronously, typically within a second. Conflicting concurrent writes to the same item are resolved last-writer-wins by internal timestamp. A strongly consistent read returns the latest version of an item if that item was last written in the Region where the read happens, and may return stale data if it was last written elsewhere. The recovery point objective equals the replication delay — usually a few seconds. An MREC table may have a replica in any Region where DynamoDB is available.
Multi-Region strong consistency (MRSC) replicates writes synchronously before the write returns, so a strongly consistent read on any replica always returns the latest version and the recovery point objective is zero. The cost is higher write and strongly-consistent-read latency. An MRSC table must be deployed in exactly three Regions — three replicas, or two replicas and a witness that holds the data but serves no requests — and it must be created from an empty table; an existing table with data cannot be converted. MRSC tables do not support TTL, local secondary indexes, or transactions, and they are confined to a Region set (US, EU or AP) rather than spanning them.
Transactions on an MREC global table are atomic only within the Region where they were invoked; replicas may briefly show a partially applied transaction as the individual writes arrive.
Choosing
Section titled “Choosing”| Requirement | Use |
|---|---|
| High-throughput reads that tolerate a second of staleness | Eventually consistent reads |
| A read that must see the write that just succeeded, in one Region | Strongly consistent read |
| Several items that must change together | A transaction |
| Multi-Region with lowest write latency, RPO of seconds | Global table in MREC mode |
| Multi-Region with strongly consistent reads everywhere, RPO zero | Global table in MRSC mode |
Financial ledgers and inventory counts are the usual reasons to reach for strong consistency; feeds, catalogues, session state and analytics rarely need it and pay double for it if they ask.