Introduction

A DynamoDB Scan does not provide a reliable sorted order across a table. If you need ordered results, the real solution is usually to design the table or an index so you can use Query with a sort key, because sorting is a query-pattern concern in DynamoDB, not a feature layered onto arbitrary full-table scans.

Why Scan Cannot Promise Order

DynamoDB stores items across partitions for scale. A scan walks through those partitions and reads items in an implementation-defined way. That means there is no meaningful global table order you can depend on during a scan.

So the short answer is:

• 'Query can return items ordered by sort key within one partition key'
• 'Scan cannot guarantee ordered results across the table'

This is one of the most important access-pattern rules in DynamoDB design.

What Works: Query on a Sort Key

If your access pattern is "give me items for one partition in ascending or descending order," use a composite key and Query.

1import boto3
2
3client = boto3.client("dynamodb")
4
5response = client.query(
6    TableName="Orders",
7    KeyConditionExpression="customer_id = :customer_id",
8    ExpressionAttributeValues={
9        ":customer_id": {"S": "cust-123"}
10    },
11    ScanIndexForward=False
12)
13
14print(response["Items"])

Here, ScanIndexForward=False gives descending order on the sort key for that partition.

That is the DynamoDB-native way to get ordering.

If You Need Global Ordering, Model an Index for It

Suppose you want orders by created_at across some alternate access pattern. The usual fix is to create a global secondary index whose key design supports that query.

For example, if you need to query all orders for one store ordered by creation time, the GSI might use:

• partition key: store_id
• sort key: created_at

Then you query the index instead of scanning the base table.

The key lesson is that DynamoDB rewards modeling around read patterns up front.

What If You Already Have to Scan

If you truly must scan, the only honest sorting option is client-side sorting after the data is read.

items = response["Items"]
items.sort(key=lambda item: item["created_at"]["S"])

This can work for small result sets, but it has clear downsides:

• you still pay the cost of the full scan
• you bring all scanned items to the client first
• sorting large result sets increases memory and latency

So client-side sorting is a fallback, not the design you should prefer.

The Real Design Question

When someone asks, "How do I scan DynamoDB in sorted order," the deeper question is usually, "Did I model the table for the access pattern I now need?"

In DynamoDB, the answer is often no. The correct fix is not a clever scan flag. It is a better primary-key or index design.

That is a major shift for people coming from relational databases, where ordering can be bolted onto many queries more flexibly.

Common Pitfalls

Assuming Scan plus a sort key on the table gives global ordering is a common misunderstanding. Sort keys only define order within items sharing the same partition key.

Using scans for user-facing ordered lists can become slow and expensive very quickly.

Sorting scanned results on the client may appear to work in development but break down under realistic data volume.

Finally, creating a GSI without aligning its partition key and sort key to a real query pattern only moves the problem rather than solving it.

Summary

• DynamoDB Scan does not guarantee sorted order across a table
• ordered retrieval in DynamoDB is normally done with Query on a sort key
• if you need a different ordering path, model a GSI that supports it
• client-side sorting after a scan is possible but is usually a fallback for small datasets only
• the right answer is usually better access-pattern design, not a special scan option