DynamoDB Sort Key Strategies: 3 Patterns and When to Use Each

A DynamoDB primary key is one or two attributes: a partition key alone, or a
partition key plus a sort key. The partition key decides which physical
partition holds an item.

The sort key decides the order of items inside that partition — and that
ordering is what makes Query powerful.

Pick the wrong sort key and you can still write data, but you lose range reads,
ordering, and several access patterns from one collection.

Coming from SQL you'd reach for an ORDER BY or a secondary index after the
fact. In DynamoDB you bake the order into the key up front, or you don't get it.

How do DynamoDB sort keys work?

A DynamoDB sort key orders items within a partition, so Query can do range reads — >=, between, begins_with — instead of fetching one item at a time. String sort keys order by UTF-8 bytes (Numbers order numerically), so design a string key (an ISO-8601 timestamp, a zero-padded number) so byte-order equals the order you want to read.

• The sort key is your in-partition index. It orders the item collection on disk, so Query can do range reads (>=, between, begins_with) instead of a single GetItem.
• String sort keys order by UTF-8 bytes (Numbers order numerically). Design a string key so byte-order equals the order you want to read — an ISO-8601 timestamp, a zero-padded number, never a raw UUID or 6/23/2026.
• One well-shaped sort key serves many access patterns. A composite key (EVT#<timestamp>) is a prefix and a range at once — no GSI needed.
• Direction is free. ScanIndexForward = false reads newest-first at the same cost; don't store reversed timestamps to fake it.

Why the sort key is the lever

Without a sort key, every item in a partition is addressable only by its full
primary key — a GetItem at best. Add a sort key and DynamoDB stores items
sorted by it within the partition, which unlocks Query.

That means range conditions (>=, between), prefix matching (begins_with),
and a ScanIndexForward flag to read ascending or descending.

Per the AWS DynamoDB Developer Guide, all items sharing a partition key form an
item collection, ordered on disk by the sort key.

So the sort key isn't just a second identifier. It's the index you query against
inside a partition.

That ordering is byte-order on the encoded sort key: strings compare by UTF-8
bytes, numbers compare numerically. This one fact drives almost every strategy
below.

If you want range queries to mean something, byte-order has to match the order you
want to read.

Strategy 1: make the sort key sortable

The most common mistake is a sort key that isn't meaningfully ordered. A random
UUID gives you uniqueness but no useful range query — "give me the last 20"
becomes impossible because byte-order is arbitrary.

Instead, encode the value you sort and filter on into the sort key, in a
representation whose byte-order equals its logical order. For timestamps that
means a lexicographically-sortable format: an ISO-8601 string or a zero-padded
epoch.

ISO-8601 was designed so string comparison equals chronological comparison —
exactly what a range query needs. Avoid formats like 6/23/2026; they sort wrong
the moment the month rolls over.

If you sort on numbers (a version counter, a score), use DynamoDB's native
Number type rather than a string, so 42 sorts after 9 instead of before
it.

If a number must live inside a composite string sort key, zero-pad it to a fixed
width.

Strategy 2: composite sort keys for hierarchy

A sort key can encode a hierarchy by concatenating segments with a delimiter,
most commonly #. One begins_with condition then selects a whole sub-tree:

begins_with(SK, "EVENT#2026-06#") returns just June's events; the broader
begins_with(SK, "EVENT#") returns all of them.

Segment ordering is a design decision. Coarse-to-fine (year → month → day) keeps
related items contiguous, so a range read stays one cheap query instead of a
scatter across the partition.

Strategy 3: control direction with ScanIndexForward

DynamoDB stores items in ascending sort-key order and reads them that way by
default. To read newest-first — the natural order for an activity feed — set
ScanIndexForward = false on the Query.

This is a read-time flag, not a schema decision: the same collection serves both
directions at the same cost. Don't invert your timestamps (storing a "reverse
epoch") just to get descending reads.

One item collection, stored once in ascending order, read either way:

Same items, same partition, same cost — only the read direction differs.

Worked example: an actor-scoped audit log

Suppose you record timestamped events produced by actors — users, services, API
keys — in a SaaS product, and you have two reads:

1. The activity stream for one actor, newest event first.
2. One actor's events within a time window (e.g. "everything between the two deploys"), for an investigation.

Both reads are scoped to a single actor, so the actor is the partition key and the
event time is the sort key. Use generic key names so the same table can hold other
entities later:

The EVT# prefix plus an ISO-8601 timestamp gives a sortable sort key. Read 1 is
Query PK = "ACTOR#u_8814" with ScanIndexForward = false for newest-first. Read
2 narrows the same partition with a between condition on the sort key:

One collection, two access patterns, no GSI — because the sort key is both a prefix
(EVT#) and a range (the timestamp). The descending read and the window read are
the same items in the same order; only the parameters differ.

Building that key condition by hand, it's easy to fumble the between bounds or
the reserved-word escaping on attribute names.

The DynamoDB Expression Builder
generates the KeyConditionExpression, the ExpressionAttributeNames, and the
ExpressionAttributeValues for a begins_with or between sort-key condition.

Copy it straight into your SDK call instead of debugging escaping at runtime.

Do it in DynoTable

Designing a sort key is iterative: write a few representative items, run the range
query, and check the rows come back in the order you expect. Doing that against a
live table in a GUI beats round-tripping through code.

Flip the sort direction, tighten the between bounds, and watch the returned
collection change without writing a line of code — the fastest way to confirm a
sort-key design before you commit it.

Pitfalls and next steps

• Sort keys must be unique within a partition. If two events can share a timestamp, append a disambiguator (a sequence number or short id) to the sort key so the composite stays unique.
• A hot partition can't be sorted around. If one actor produces far more events than the rest, the sort key won't save you — you need a partition-key design that spreads the load. See single-table design.
• A second sort order needs a second index. The base table's sort key gives one ordering. To order the same items differently (by event type, say), add a GSI with a different sort key — weighing the local vs global secondary index trade-offs.
• Don't reach for Scan to "sort later". Sorting client-side after a Scan reads the whole table and throws ordering away; that's the Scan footgun. Push the order into the sort key instead.

Once the key condition is right, try DynoTable to model the
collection, run the ascending and descending queries side by side, and verify your
sort-key strategy against real data before it ships.