Introduction

Global Secondary Indexes in DynamoDB do not support strongly consistent reads. That is the short answer, and it matters architecturally. A query against a GSI is always eventually consistent, which means updates to the base table may take a short time to appear in the index results.

What a GSI Actually Is

A Global Secondary Index is an additional access path built from data in the base table. It has its own partition and sort key definition and is maintained asynchronously from the main item storage.

That asynchronous maintenance is the reason strong consistency is not available for GSIs. The index is not read directly from the base table's primary-storage view in the same way a strongly consistent base-table read can be.

What Happens If You Ask for Strong Consistency

When querying a GSI, you should not rely on ConsistentRead=True as a solution, because GSIs are eventually consistent only.

Example with boto3:

1import boto3
2
3dynamodb = boto3.resource("dynamodb")
4table = dynamodb.Table("Orders")
5
6response = table.query(
7    IndexName="CustomerIdIndex",
8    KeyConditionExpression=boto3.dynamodb.conditions.Key("customer_id").eq("123"),
9)
10
11print(response["Items"])

That query is eventually consistent by nature. Even if a recent write already succeeded on the base table, the GSI may lag briefly before reflecting it.

If You Need the Latest Data

You have a few design options:

• read from the base table when strong consistency is required
• use a Local Secondary Index if the access pattern and table design allow it
• accept eventual consistency and add retry or refresh behavior
• redesign the write and read flow so stale GSI reads are acceptable

The right answer depends on whether the application truly needs read-after-write guarantees for that access path.

Example: Read-After-Write Surprise

Suppose you write an order and then immediately query a GSI by customer_id. The base table write may be committed, but the GSI entry may not yet be visible. If your code assumes instant visibility, the query can appear to "miss" the item temporarily.

That is not a bug in DynamoDB. It is the consistency model you chose by reading through a GSI.

This is why GSI-based workflows often need one of:

• idempotent retries
• polling with backoff
• a fallback read path from the base table

Do Not Confuse GSIs with LSIs

Local Secondary Indexes are different. LSIs share the table partition key and can participate in strongly consistent reads when read through the table. GSIs do not have that guarantee.

So when people ask "can DynamoDB indexes be strongly consistent," the correct answer is "LSIs can participate in that model; GSIs cannot."

That distinction is one of the most important DynamoDB design rules.

It also affects schema design early. If a query pattern cannot tolerate stale results, that is usually a sign that the access path belongs on the base table or on an LSI-compatible key design rather than on a GSI.

Common Pitfalls

• Assuming all DynamoDB indexes support strong consistency equally.
• Writing an item and then immediately querying the GSI as if read-after-write consistency were guaranteed.
• Treating temporary GSI lag as random failure rather than as normal eventual consistency.
• Using a GSI for an access pattern that actually requires immediate consistency.
• Forgetting that LSI and GSI consistency behavior is not the same.

Summary

• GSI reads in DynamoDB are eventually consistent only.
• Recent base-table writes may take a short time to appear in a GSI query.
• If strong consistency is required, read from the base table or redesign the access pattern.
• Do not assume ConsistentRead=True solves GSI lag.
• Distinguish GSIs from LSIs when reasoning about consistency guarantees.