Is DynamoDB eventually consistent?
By default, yes. DynamoDB reads are eventually consistent: a read immediately after a write may not reflect that write, but repeating it a short time later returns the up-to-date item. You can opt into strongly consistent reads on tables and LSIs; global secondary indexes are always eventually consistent.
Eventually consistent (the default)
An eventually consistent read may not reflect a just-completed write. Repeat the read a moment later and it returns the current value. This mode is the default, and it is billed at half the rate of a strongly consistent one.
Strongly consistent reads
Set ConsistentRead: true to get the most recent committed data (a strongly consistent read). This is supported on the base table and local secondary indexes (LSIs) — but not on global secondary indexes (GSIs) or DynamoDB Streams, which are always eventually consistent.
The GSI exclusion is enforced at the API, not left to you to respect: a Query on a global secondary index with ConsistentRead: true fails the whole request rather than quietly downgrading it (the exact rejection).
What the choice costs
"Half the price" is the documented rule; here is what it comes to. Take 1,000 reads per second of 4 KB items in us-east-1, and nothing else:
| Consistency | Read units per read | On-demand / month | Provisioned / month |
|---|---|---|---|
| Eventually consistent | 0.5 | $164.25 | $47.45 (500 RCU) |
| Strongly consistent | 1 | $328.50 | $94.90 (1,000 RCU) |
Inputs, so you can check it: 2,628,000 seconds in a 730-hour month, $0.125 per million read request units, $0.00013 per RCU-hour. A 4 KB item is one read unit, halved for eventual consistency.
So $164 a month is the standing price of never reading a stale item on this workload. That is cheap for an account balance and a waste for a product listing, which is why the flag is per-request rather than per-table. Price your own numbers in the pricing calculator.
Why it works this way
DynamoDB automatically replicates your data across three Availability Zones. Eventual consistency lets reads be served without waiting on every copy — faster and cheaper; strong consistency returns the most up-to-date data.
What about multi-Region (global tables)?
Cross-Region replication has its own consistency setting. Global tables default to multi-Region eventual consistency (MREC), where changes replicate to other Regions typically within a second or less. You can instead create a global table with multi-Region strong consistency (MRSC): writes replicate synchronously to at least one other Region, and strongly consistent reads on any replica always return the latest version of an item.
Go deeper
Read DynamoDB consistency for the full trade-offs. Download DynoTable to toggle read consistency on your queries.
References
- DynamoDB read consistency — Amazon DynamoDB Developer Guide
- How DynamoDB global tables work — Amazon DynamoDB Developer Guide
- Query — Amazon DynamoDB API Reference
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
Last verified 2026-07-13 against the official AWS documentation linked above; unit prices re-checked 2026-07-28.
The GSI rejection was reproduced 2026-07-28 against DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) via @aws-sdk/client-dynamodb 3.1095.0, and the cost table was computed from the same pricing data the calculator uses.