DynamoDB Query ConsistentRead boundary: per-page strong consistency without cross-page snapshot

Question

Goal
Paginate a large DynamoDB Query result set bounded by a partition-key equality and optional sort-key range while preserving a stable read view across pages.

Constraint
DynamoDB enforces a 1 MB response limit per Query page and returns LastEvaluatedKey for continuation through ExclusiveStartKey. ConsistentRead=true makes each individual page strongly consistent, but the service does not document point-in-time snapshot isolation across multiple pages. Items inserted, updated, or deleted between fetches can appear, disappear, or change on later pages.

Uncertainty
Assuming current DynamoDB API behavior, it is unresolved whether an application should narrow the sort-key boundary and accept newly written items appearing between pages, or use a single-page atomic read pattern instead. The boundary between per-page strong consistency and cross-page visibility remains a design decision.

Does DynamoDB guarantee that consecutive Query pages with ConsistentRead=true reflect a single point-in-time snapshot? If not, which bounded Query pattern best approximates a stable large-dataset read without scanning the full table? Is TransactGetItems the only supported atomic alternative for reading multiple items consistently?

Tasadduq Burney · Answer

Consistency Boundaries in Paginated Queries
No, DynamoDB does not guarantee that consecutive Query pages using ConsistentRead=true reflect a single point-in-time snapshot. Strong consistency is applied only to the individual request. Because each page fetch is an independent API call, any writes occurring between the completion of page N and the initiation of page N+1 can result in items appearing, disappearing, or changing in the subsequent result set.

Analysis of Consistency Behavior
When you provide an ExclusiveStartKey, DynamoDB resumes the scan from the last evaluated item. However, it does not "lock" the state of the partition or create a server-side cursor with snapshot isolation. The ConsistentRead flag ensures that the current page reflects the most recent successful write at the moment that specific request is processed, not the moment the first page of the pagination sequence was requested.

Patterns for Stable Large-Dataset Reads
Since TransactGetItems is limited to 25 items and requires known keys, it is not a viable replacement for paginating large result sets. To approximate a stable read, consider these patterns:

Time-Bounded Sort Keys: If your sort key is a timestamp, query for a range that ends at a specific T-minus value (e.g., SortKey < [CurrentTime - 5 seconds]). This creates a logical snapshot by ignoring any data written during the pagination process.
  Application-Level Versioning: Include a version or timestamp attribute in your items. The application can then filter out items updated after the initial page request timestamp.
  Point-in-Time Recovery (PITR): For absolute snapshots of massive datasets, use PITR to restore the table to a new instance at a specific second, then perform the read against the restored table.

Verification Step
To verify this behavior in your environment, you can run the following test:

Execute a Query with ConsistentRead=true and a limit that forces a LastEvaluatedKey.
  Perform a PutItem or UpdateItem on an item that falls within the remaining sort-key range but has not yet been returned.
  Execute the second Query using the ExclusiveStartKey. The updated or new item will appear, confirming the lack of cross-page snapshot isolation.

Diagnostic Detail Required: Are you using a timestamp-based sort key? If so, the time-bounded range pattern is the recommended architectural solution.

DynamoDB Query ConsistentRead boundary: per-page strong consistency without cross-page snapshot

Goal

Constraint

Uncertainty

1 answer

Consistency Boundaries in Paginated Queries

Analysis of Consistency Behavior

Patterns for Stable Large-Dataset Reads

Verification Step

Your perspective belongs here.

0 question comments