DynoTable

Querying & Sorting

You add a filter to a Scan because it feels like SQL WHERE, then pay to read every item in the table while the console shows twenty matching rows. That pattern is the most common DynamoDB cost surprise on production bills.

Reads in DynamoDB are keyed. Query walks one item collection in sort-key order; Scan touches the whole table. Filter expressions discard rows after capacity is charged. Pagination must carry LastEvaluatedKey; sorting happens via the sort key of the index you chose, not an arbitrary column in application memory.

What you can do after

  • Choose Query vs Scan for a feature and defend the choice with partition scope.
  • Page through large result sets without dropping or duplicating items.
  • Apply filters at the key condition when possible and know what a post-read filter still costs.
  • Encode sort order in the sort key — descending reads, mutable keys, zero-padding for numeric order.

Reading order

  1. Query vs Scan — the billing decision every other read guide assumes you understand.
  2. Pagination — LastEvaluatedKey, page loops, and why Limit is not "rows returned."
  3. Filtering strategies — key conditions vs filter expressions; push selectivity as far left as the keys allow.
  4. Why Scan is slow and expensive — table growth vs partition growth; when a one-off Scan is acceptable.
  5. Parallel scans — segmented Scan for bulk export; the throughput trade-off.
  6. Sort key strategies — design the sort key so order is on disk, not in your app.
  7. Query descending order — ScanIndexForward and newest-first reads.
  8. Mutable sort keys — when changing the sort key is a delete+put and what that costs on GSIs.
  9. Zero-padding sort — fixed-width numeric sort keys so ORDER#00042 sorts before ORDER#00043.
0 of 10 readQuiz
DynamoDB Query vs Scan: Which to Use, and Why (w/ Examples)
Query vs Scan in DynamoDB — Query reads one item collection and bills matched items, Scan reads the whole table before any FilterExpression runs.
Beginner7 min read
DynamoDB Pagination: LastEvaluatedKey Explained
How DynamoDB pagination works — loop on LastEvaluatedKey and ExclusiveStartKey, why Limit is not a page size, and how to expose a stateless cursor.
Beginner7 min read
DynamoDB Filtering Strategies
DynamoDB filtering strategies compared — partition key, sort key, sparse indexes, and FilterExpression — and which one actually cuts your read bill.
Intermediate8 min read
Why a DynamoDB Scan Is Slow and Expensive
Why a DynamoDB Scan is slow and expensive, what it actually bills you for, and how to turn a reflexive Scan into a keyed Query that costs a fraction.
Beginner7 min read
DynamoDB Parallel Scans
How DynamoDB parallel scans split a full-table read across workers with Segment and TotalSegments, when they help, and the throughput footgun to avoid.
Advanced7 min read
DynamoDB Sort Key Strategies: 3 Patterns, When to Use Each
DynamoDB sort key strategies for range reads — design a sort key whose byte order matches your read order, so one Query serves many access patterns.
Intermediate8 min read
How to Query DynamoDB in Descending Order
Query DynamoDB in descending order with ScanIndexForward=false — newest-first results, why sorting happens on the sort key, and why reverse reads are free.
Beginner7 min read
Sorting DynamoDB on a Changing Attribute
Sorting DynamoDB on a changing attribute — why a key attribute is immutable, the delete-and-recreate pattern, and moving it to a GSI sort key instead.
Intermediate7 min read
Zero-Padding Sort Keys in DynamoDB
Why "10" sorts before "2" in a DynamoDB string sort key, and how fixed-width zero-padding makes lexicographic byte order match numeric order.
Intermediate5 min read
Knowledge checkTake the quiz
Check what you’ve learned in this section.

A Query on PK = TENANT#acme with SK begins_with ORDER# reads only that tenant's orders. A Scan with filter status = OPEN on a ten-million-item table still rounds up capacity for millions of reads. At on-demand pricing in us-east-1, a single 4 KB read unit costs about $0.000000125 — trivial per call, brutal at table scale. The pricing calculator prices your actual read rate and item size.

Parallel scans split a Scan across workers for bulk export jobs. They multiply read throughput and cost proportionally — useful for one-time migrations, dangerous as a cron job on a large table. Mutable sort keys force delete-and-put when you change the sort position of an item, which doubles writes on any GSI that indexes that key. Zero-padding ORDER#00042 vs ORDER#42 fixes lexicographic order when your sort key is a string carrying numeric IDs.

In DynoTable

The free query builder composes a full Query or Scan request with pagination loop code in eight export targets. In the app, the visual filter builder picks an index, shows a derived Query vs Scan badge, and flags scan-filters before you run.

Download DynoTable and execute these reads against a live table. The query cost status bar gives a pre-run hint (~N items · ~R RCU when the plan is known) on Workbench and PartiQL tabs so surprise bills surface before you commit.