Scan vs query performance in AWS - Visual Side-by-Side Comparison

Process Flow - Scan vs query performance

Start Request

↓

Choose Operation

↓

Query

↓

Use Key

↓

Fetch Items

↓

Return Result

The flow shows how a request chooses between Query and Scan. Query uses keys to fetch items directly. Scan reads the whole table and then filters.

Execution Sample

AWS

Query: Get items where PK = 'User#123'
Scan: Read all items, filter where Age > 30

This example compares Query fetching items by key versus Scan reading all items and filtering.

Process Table

Step	Operation	Action	Items Processed	Items Returned	Performance Impact
1	Query	Use partition key to find items	10	10	Fast, reads only matching items
2	Scan	Read entire table	1000	50	Slow, reads all items then filters
3	Query	Return matched items	10	10	Efficient, minimal read
4	Scan	Filter items after read	1000	50	Inefficient, high read cost
5	Query	Complete	10	10	Low latency, low cost
6	Scan	Complete	1000	50	High latency, high cost

💡 Query stops after reading matching keys; Scan stops after reading entire table.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Items Processed (Query)	0	10	10	10	10	10
Items Processed (Scan)	0	0	1000	1000	1000	1000
Items Returned (Query)	0	0	0	10	10	10
Items Returned (Scan)	0	0	0	0	50	50

Key Moments - 2 Insights

Why does Scan process more items than Query even if fewer items are returned?

Scan reads the entire table (1000 items) before filtering, while Query reads only matching items (10). See execution_table rows 1 and 2.

Does Query always return fewer items than Scan?

Not necessarily. Query returns items matching the key condition, which can be many or few. Scan returns filtered items after reading all. See rows 3 and 4.

Visual Quiz - 3 Questions

Look at the execution_table, how many items does Query process at step 1?

A 1000

B 10

C 50

D 0

💡 Hint

Check 'Items Processed' column for Query at step 1 in execution_table.

At which step does Scan filter items after reading the whole table?

A Step 4

B Step 2

C Step 3

D Step 1

💡 Hint

Look for 'Filter items after read' action in execution_table.

If the table size doubles, how would Scan's 'Items Processed' change at step 2?

A It stays the same

B It halves

C It doubles

D It becomes zero

💡 Hint

Scan reads the entire table, so 'Items Processed' depends on table size (see variable_tracker).

Concept Snapshot

Scan vs Query Performance:
- Query uses keys to fetch matching items only.
- Scan reads entire table then filters.
- Query is faster and cheaper for targeted reads.
- Scan is slower and costly for large tables.
- Prefer Query when possible for efficiency.

Full Transcript

This visual execution compares Scan and Query operations in AWS DynamoDB. Query uses a partition key to directly fetch matching items, processing only those items. Scan reads the entire table and then filters items, processing many more items than it returns. The execution table shows Query processing 10 items and returning 10, while Scan processes 1000 items but returns only 50. This difference explains why Query is faster and more efficient. Key moments clarify common confusions about item processing and return counts. The quiz tests understanding of these steps and performance impacts. The snapshot summarizes that Query is preferred for performance, while Scan is costly and slower.