DynamoDB Strongly Consistent vs Eventually Consistent Reads

You update an item, immediately read it back, and get the old value. The write succeeded — a moment later the same read returns the new value. Nothing is broken: you've hit DynamoDB's default eventually consistent read, and you can opt out of it per request.

This is one of the few correctness knobs DynamoDB hands you directly, and it has a real price attached. Getting it right means knowing what each mode guarantees, what it costs, and where strong reads simply aren't available.

What is the difference between strongly and eventually consistent reads in DynamoDB?

An eventually consistent read (the default) is served by any replica, so it can briefly return stale data right after a write, but costs half as much. A strongly consistent read, opted into per request with ConsistentRead=true, is routed to the partition leader and always reflects every committed write — at 2× the read capacity.

• Eventually consistent (the default) — may briefly return stale data right after a write. Cheapest read mode.
• Strongly consistent — always reflects every write committed before the read. Opt in per request with ConsistentRead=true.
• Strong reads cost 2× eventual. A strongly consistent read consumes twice the read capacity of an eventually consistent one for the same data.
• Not everywhere. You get strong reads on the base table and on a Local Secondary Index. A Global Secondary Index is eventual-only — no opt-in.
• Default to eventual. Reach for strong only when reading your own just-written data and stale-by-a-moment would be wrong.

The problem: a read that doesn't see the latest write

Say you run user accounts. A user changes their notification email, your app writes the update, and the confirmation screen immediately re-reads the profile to show the new address. With the default read mode, that re-read can land on a replica that hasn't received the change yet — so the user sees their old email and assumes the save failed.

The window is small (typically well under a second) and it closes on its own. But "usually correct" isn't good enough for a read-after-write confirmation. That's exactly the case strong consistency exists for.

Why eventual consistency happens

DynamoDB stores every partition on three storage nodes — one primary and two replicas — across separate Availability Zones. A write is acknowledged once it lands on the primary and one replica; it then propagates to the third node asynchronously.

Reads, to spread load, can be served by any of the three nodes. An eventually consistent read may hit a node that hasn't yet received your most recent write — so it returns a slightly stale value. A strongly consistent read is routed to the leader for the partition, which always holds the latest committed data, so it never returns stale results.

That replication lag is the entire difference. It also explains the 2× cost: strong reads can't be load-balanced across replicas the way eventual reads can, so DynamoDB prices them at twice the capacity.

The cost, made concrete

Reads are metered in Read Capacity Units (RCU), each covering up to 4 KB. One RCU buys one strongly consistent read or two eventually consistent reads of a 4 KB item. So flipping ConsistentRead=true on a hot read path doubles its read cost — on a high-traffic endpoint that's a line-item you'll notice.

Model the difference for your own item sizes and request rates with the DynamoDB pricing calculator before you make strong reads your default — it's rarely worth paying twice across the board.

Where strong reads are (and aren't) available

A GSI maintains its own copy of the data, replicated from the base table asynchronously, so it can never offer a strong read. If an access pattern genuinely needs read-after-write and you were planning to serve it from a GSI, that's a signal to serve it from the base table or an LSI instead.

Pitfalls + next steps

• Don't make strong reads the default. Most reads tolerate a sub-second stale window; paying 2× everywhere is wasted spend.
• Don't expect read-after-write from a GSI. It's eventual by design — see why a GSI is eventually consistent.
• Transactions read strongly. TransactGetItems is always strongly consistent — see DynamoDB transactions.
• Consistency interacts with capacity. The 2× multiplier ties straight into on-demand vs provisioned cost planning.

Want to explore your DynamoDB tables and indexes without writing API calls? Download DynoTable and inspect your data directly.