DynamoDB Read Consistency

DynamoDB stores copies of your data across multiple physical locations for reliability. When you read data, you need to decide whether you want the latest possible value or if a slightly older value is acceptable. This choice is called read consistency.

Why Consistency Matters

Imagine a scoreboard at a cricket match. The official scorekeeper updates the score after every ball. A display board in the stadium shows the score to spectators. If the display board updates every 5 seconds, there is a tiny lag between the actual score and what spectators see.

DynamoDB faces a similar challenge. When you write data, it must be copied to multiple storage locations. If you read data immediately after writing it, you might read from a location that has not received the latest copy yet.

How DynamoDB Stores Data

DynamoDB automatically replicates every write across three storage nodes within an AWS region. A write is confirmed to you after at least two of the three nodes acknowledge it.

Your Application
      │
      ▼  Write: "Balance = 5000"
DynamoDB
      ├── Node A ✓ (updated)
      ├── Node B ✓ (updated) ← Write confirmed after 2 nodes
      └── Node C  (updating in background)

If you read immediately after, Node C might return "Balance = 4500" (old value)

Two Types of Read Consistency

Eventually Consistent Read (Default)

DynamoDB reads from any of its three storage nodes. If you read immediately after a write, you might get data that is slightly behind (milliseconds old). Within about one second, all nodes converge to the same value.

Cost: 0.5 RCU per 4 KB of data read.

Use when: A tiny, brief lag is acceptable. Examples include reading a product description, fetching a news article, or loading a user's profile picture URL.

Strongly Consistent Read

DynamoDB reads from the primary node (the leader node that received the write first). This guarantees you always get the most up-to-date value, even if you read one millisecond after writing.

Cost: 1 RCU per 4 KB of data read — double the cost of an eventually consistent read.

Use when: You cannot afford to read stale data. Examples include a bank account balance, an inventory counter, or a ticket availability check.

Diagram: Eventual vs Strong Consistency

Time →   T=0          T=200ms        T=1000ms
         ─────────────────────────────────────
Write:   Balance=5000 written

Node A:  5000 ✓       5000 ✓         5000 ✓
Node B:  5000 ✓       5000 ✓         5000 ✓
Node C:  4500 (old)   5000 ✓         5000 ✓

Eventually Consistent Read at T=200ms → might get 4500 or 5000
Strongly Consistent Read at T=200ms  → always gets 5000
Eventually Consistent Read at T=1000ms → always gets 5000 (converged)

How to Specify Read Consistency

You set the consistency level per read operation, not at the table level. This means different parts of your application can use different consistency levels on the same table.

GetItem with Strongly Consistent Read:
{
  "TableName": "BankAccounts",
  "Key": { "AccountID": { "S": "ACC001" } },
  "ConsistentRead": true
}

GetItem with Eventually Consistent Read (default):
{
  "TableName": "BankAccounts",
  "Key": { "AccountID": { "S": "ACC001" } },
  "ConsistentRead": false
}

Consistency and Global Secondary Indexes

Reads on Global Secondary Indexes (GSIs) are always eventually consistent. You cannot request a strongly consistent read on a GSI. This is a key limitation to be aware of when designing your access patterns. If you need strongly consistent reads, always read from the base table using its primary key.

Consistency and DynamoDB Streams

DynamoDB Streams always capture changes in the order they happen, regardless of read consistency settings. Streams reflect the actual write order.

Choosing Between the Two

Cost Implications

Because strongly consistent reads cost twice as many RCUs as eventually consistent reads, defaulting to strongly consistent reads unnecessarily doubles your DynamoDB read costs. Always ask: "Does this read absolutely need the latest value?" If the answer is no, use the default eventually consistent read.

Summary

• DynamoDB replicates data across three nodes within a region.
• Eventually consistent reads are faster and cheaper but may return data that is a fraction of a second old.
• Strongly consistent reads always return the latest value but cost twice as many RCUs.
• Set ConsistentRead: true on individual read operations to request strong consistency.
• GSI reads are always eventually consistent — no exception.