Scan vs Query performance comparison in DynamoDB - Visual Side-by-Side Comparison

Concept Flow - Scan vs Query performance comparison

Start Operation

↓

Use Partition Key

↓

Fetch Matching Items

↓

Return Results

↓

End Operation

Shows how Query uses keys to fetch matching items efficiently, while Scan reads the whole table and filters later.

Execution Sample

DynamoDB

Query: SELECT * FROM table WHERE partition_key = 'A'
Scan: SELECT * FROM table WHERE attribute = 'A'

Query fetches items by partition key directly; Scan reads all items and filters after.

Execution Table

Step	Operation	Items Read	Items Returned	Performance Impact
1	Query starts	0	0	Fast start, uses partition key
2	Query reads matching partition	3	3	Reads only relevant items
3	Query returns results	3	3	Efficient, low cost
4	Scan starts	0	0	Starts reading entire table
5	Scan reads all items	10	3	Reads all items, filters later
6	Scan returns filtered results	10	3	Slower, higher cost
7	End	-	-	Query is faster and cheaper than Scan

💡 Scan reads all 10 items, Query reads only 3 matching items; Query is more efficient.

Variable Tracker

Variable	Start	After Query Step 2	After Scan Step 5	Final
Items Read	0	3	10	10
Items Returned	0	3	3	3

Key Moments - 2 Insights

Why does Query read fewer items than Scan?

Because Query uses the partition key to directly access matching items (see execution_table row 2), while Scan reads the entire table (row 5) and filters afterward.

Does Scan always return more items than Query?

No, Scan can return the same number of items as Query (see rows 3 and 6), but it reads more items internally, making it slower and more costly.

Visual Quiz - 3 Questions

Look at the execution_table, how many items does Query read at step 2?

A 3

B 10

C 0

D 5

💡 Hint

Check the 'Items Read' column at step 2 in execution_table.

At which step does Scan finish reading all items?

A Step 4

B Step 5

C Step 6

D Step 3

💡 Hint

Look for 'Scan reads all items' in execution_table step 5.

If the table had 1000 items but only 3 matched the Query, how would Query's 'Items Read' change?

A It would read 1000 items

B It would read 0 items

C It would read 3 items

D It would read 500 items

💡 Hint

Query reads only matching partition key items, as shown in variable_tracker.

Concept Snapshot

Query uses partition key to fetch matching items directly.
Scan reads the entire table and filters afterward.
Query is faster and cheaper than Scan.
Use Query when you know the partition key.
Scan is costly and slower for large tables.
Always prefer Query for performance.

Full Transcript

This visual execution compares DynamoDB Query and Scan operations. Query uses the partition key to directly fetch matching items, reading fewer items and returning results quickly. Scan reads the entire table, then filters items, resulting in more items read and slower performance. The execution table shows Query reading 3 items and Scan reading 10 items to return the same 3 results. Variable tracking confirms Query reads fewer items. Key moments clarify why Query is more efficient and when Scan returns the same number of items but at higher cost. The quiz tests understanding of items read and performance differences. Remember, Query is best when you know the partition key; Scan should be avoided for large tables due to cost and speed.

Practice

1. Which DynamoDB operation is generally faster when you know the partition key of the item you want to retrieve?

easy

A. Scan

B. UpdateItem

C. Query

D. DeleteItem

Solution

1. Step 1: Understand Query operation

   Query uses the partition key to directly find matching items, making it efficient.

2. Step 2: Compare with Scan operation

   Scan reads the entire table, which is slower and less efficient.

3. Final Answer:

   Query -> Option C

4. Quick Check:

   Query is faster for known keys [OK]

Hint: Use Query when you know the partition key for speed [OK]

Common Mistakes:

• Thinking Scan is faster because it reads all data
• Confusing Query with Scan
• Assuming UpdateItem is for reading data

2. Which of the following is the correct syntax to perform a Query operation in DynamoDB using AWS SDK for JavaScript?

easy

A. dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pkval', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pkval': '123' } })

B. dynamoDbClient.scan({ TableName: 'MyTable', KeyConditionExpression: 'PartitionKey = 123' })

C. dynamoDbClient.query({ TableName: 'MyTable', FilterExpression: 'PartitionKey = 123' })

D. dynamoDbClient.getItem({ TableName: 'MyTable', Key: { PartitionKey: '123' } })

Solution

1. Step 1: Identify correct Query syntax

   Query requires KeyConditionExpression with placeholders and attribute names/values.

2. Step 2: Check options for correct usage

   dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pkval', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pkval': '123' } }) uses KeyConditionExpression and ExpressionAttributeNames/Values correctly.

3. Final Answer:

   dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pkval', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pkval': '123' } }) -> Option A

4. Quick Check:

   Query needs KeyConditionExpression [OK]

Hint: Query needs KeyConditionExpression, not FilterExpression [OK]

Common Mistakes:

• Using FilterExpression instead of KeyConditionExpression for Query
• Using scan method with KeyConditionExpression
• Confusing getItem with query syntax

3. Given a DynamoDB table with 1000 items, what will be the main difference in performance between these two operations?
dynamoDbClient.scan({ TableName: 'MyTable' })
and
dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pk', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pk': '123' } })

medium

A. Scan reads all 1000 items; Query reads only matching items, so Query is faster.

B. Scan is faster because it reads all items at once; Query is slower due to filtering.

C. Both operations have the same speed because they access the same table.

D. Query reads all items; Scan reads only matching items.

Solution

1. Step 1: Understand Scan operation

   Scan reads every item in the table, so it processes all 1000 items.

2. Step 2: Understand Query operation

   Query uses the partition key to read only matching items, which is faster.

3. Final Answer:

   Scan reads all items; Query reads only matching items, so Query is faster. -> Option A

4. Quick Check:

   Scan reads all; Query reads matching [OK]

Hint: Scan reads whole table; Query reads only matching keys [OK]

Common Mistakes:

• Thinking Scan is faster because it reads all data at once
• Confusing Query reading all items
• Assuming both have same speed

4. You wrote this DynamoDB Query code but it returns no results:

const params = { TableName: 'MyTable', KeyConditionExpression: 'PartitionKey = :pk', ExpressionAttributeValues: { ':pk': '123' } };
const data = await dynamoDbClient.query(params);

What is the most likely error?

medium

A. Missing ExpressionAttributeNames for reserved word PartitionKey

B. Using Scan instead of Query

C. TableName is misspelled

D. Incorrect KeyConditionExpression syntax; should use #pk = :pk

Solution

1. Step 1: Check KeyConditionExpression syntax

   KeyConditionExpression requires placeholders for attribute names like #pk defined in ExpressionAttributeNames.

2. Step 2: Identify missing ExpressionAttributeNames

   The code uses 'PartitionKey' directly without ExpressionAttributeNames, causing no matches.

3. Final Answer:

   Incorrect KeyConditionExpression syntax; should use #pk = :pk -> Option D

4. Quick Check:

   Reserved words need placeholders in KeyConditionExpression [OK]

Hint: Use placeholders for reserved words in KeyConditionExpression [OK]

Common Mistakes:

• Not using ExpressionAttributeNames for reserved words
• Confusing Scan and Query methods
• Misspelling TableName

5. You want to retrieve all items where the attribute 'Status' equals 'Active' from a large DynamoDB table. The table's partition key is 'UserId'. Which approach is best for performance and cost?

hard

A. Use Query with KeyConditionExpression on 'UserId' and FilterExpression on 'Status' = 'Active'.

B. Create a Global Secondary Index (GSI) on 'Status' and Query the GSI for 'Active' items.

C. Use Scan with a FilterExpression on 'Status' = 'Active' to get all matching items.

D. Use Scan without any filters to get all items and then filter in application code.

Solution

1. Step 1: Understand limitations of Scan and Query

   Scan reads entire table and is costly; Query requires partition key, but 'Status' is not the partition key.

2. Step 2: Use GSI for efficient querying

   Creating a GSI on 'Status' allows Query on 'Status' attribute efficiently without scanning.

3. Final Answer:

   Create a Global Secondary Index (GSI) on 'Status' and Query the GSI for 'Active' items. -> Option B

4. Quick Check:

   GSI enables efficient queries on non-key attributes [OK]

Hint: Use GSI to query non-key attributes efficiently [OK]

Common Mistakes:

• Using Scan with filters on large tables
• Trying to Query without partition key
• Filtering in application instead of database