Why Scan reads the entire table in DynamoDB - Visual Breakdown

Concept Flow - Why Scan reads the entire table

Start Scan Operation

↓

Read First Page of Items

↓

Check if More Pages Exist?

No→End Scan

Yes↓

Read Next Page of Items

↩Back to Check

Scan reads all items page by page until no more pages remain, covering the entire table.

Execution Sample

DynamoDB

Scan operation on DynamoDB table
Reads items page by page
Stops when no more pages

This Scan reads every item in the table by paging through all data.

Execution Table

Step	Action	Items Read	More Pages?	Next Step
1	Start Scan	0	Yes	Read first page
2	Read first page	100	Yes	Read next page
3	Read second page	200	Yes	Read next page
4	Read third page	300	No	End Scan
5	End Scan	300	No	Stop

💡 No more pages to read, entire table scanned

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
ItemsRead	0	100	200	300	300
MorePages	Yes	Yes	Yes	No	No

Key Moments - 2 Insights

Why does Scan read all items even if I only want a few?

Scan reads every item page by page until no pages remain, as shown in execution_table rows 2-4, so it always covers the whole table.

What does 'More Pages?' mean in the Scan process?

'More Pages?' indicates if there are more items to read beyond the current page. If Yes, Scan continues reading next pages (rows 2 and 3). If No, Scan ends (row 4).

Visual Quiz - 3 Questions

Look at the execution_table, how many items have been read after step 3?

A 200

B 100

C 300

D 0

💡 Hint

Check the 'Items Read' column at step 3 in execution_table

At which step does the Scan operation stop reading more pages?

A Step 2

B Step 3

C Step 4

D Step 1

💡 Hint

Look at 'More Pages?' column in execution_table where it changes to No

If the table had 500 items and each page reads 100 items, how many steps would the Scan need to finish?

A 4 steps

B 5 steps

C 6 steps

D 3 steps

💡 Hint

Each page reads 100 items, so 500 items means 5 pages to read

Concept Snapshot

Scan reads all items in a DynamoDB table by paging through data.
It reads one page at a time until no more pages remain.
Each page contains a set number of items (e.g., 100).
Scan always covers the entire table, which can be slow for large tables.
Use Query instead to read specific items efficiently.

Full Transcript

The Scan operation in DynamoDB reads the entire table by fetching items page by page. It starts by reading the first page of items, then checks if more pages exist. If yes, it continues reading the next pages until no more pages remain. This means Scan always reads all items in the table, which can be slow for large tables. The execution table shows each step with the number of items read and whether more pages exist. The variable tracker shows how the count of items read increases with each step. Beginners often wonder why Scan reads all items even if only a few are needed; this is because Scan does not filter items before reading. The 'More Pages?' column indicates if the Scan should continue reading. Understanding this flow helps to choose the right operation for efficient data access.

Practice

1. Why does the Scan operation in DynamoDB read the entire table?

easy

A. Because it only reads the first item in the table

B. Because it uses indexes to find items quickly

C. Because it checks every item to find matches without using keys

D. Because it reads only the items with matching partition keys

Solution

1. Step 1: Understand Scan operation behavior

   Scan reads every item in the table one by one to find matching data because it does not use keys or indexes.

2. Step 2: Compare with other operations

   Unlike Query, which uses keys to find items quickly, Scan must read the whole table.

3. Final Answer:

   Because it checks every item to find matches without using keys -> Option C

4. Quick Check:

   Scan reads all items = B [OK]

Hint: Scan reads all items; Query uses keys for speed [OK]

Common Mistakes:

• Thinking Scan reads only some items
• Confusing Scan with Query
• Assuming Scan uses indexes

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

easy

A. dynamodb.query({ TableName: 'MyTable' }, callback);

B. dynamodb.scan({ TableName: 'MyTable' }, callback);

C. dynamodb.getItem({ TableName: 'MyTable' }, callback);

D. dynamodb.update({ TableName: 'MyTable' }, callback);

Solution

1. Step 1: Identify Scan method usage

   The Scan operation uses the scan method with the table name as a parameter.

2. Step 2: Differentiate from other methods

   query is for key-based queries, getItem fetches a single item, and update modifies items.

3. Final Answer:

   dynamodb.scan({ TableName: 'MyTable' }, callback); -> Option B

4. Quick Check:

   Scan uses scan() method = A [OK]

Hint: Scan uses scan() method, not query() or getItem() [OK]

Common Mistakes:

• Using query() instead of scan()
• Confusing getItem() with scan()
• Using update() for reading data

3. Given a DynamoDB table with 1000 items, what will be the result of a Scan operation without any filter?

medium

A. It returns all 1000 items by reading the entire table

B. It returns only items with a specific partition key

C. It returns no items because no filter is applied

D. It returns only the first 10 items by default

Solution

1. Step 1: Understand Scan without filters

   Scan reads every item in the table and returns all items if no filter is applied.

2. Step 2: Confirm behavior on item count

   Since the table has 1000 items, Scan returns all 1000 items.

3. Final Answer:

   It returns all 1000 items by reading the entire table -> Option A

4. Quick Check:

   Scan without filter returns all items = A [OK]

Hint: Scan returns all items if no filter is set [OK]

Common Mistakes:

• Assuming Scan returns only some items by default
• Confusing Scan with Query filtering
• Thinking Scan returns no items without filter

4. You wrote this code to scan a DynamoDB table but it returns only a few items instead of all. What is the likely issue?

const params = { TableName: 'MyTable' };
dynamodb.scan(params, (err, data) => {
  if (err) console.log(err);
  else console.log(data.Items);
});

medium

A. The scan method is incorrect; it should be query

B. The table is empty, so no items are returned

C. Scan only returns items with a filter, so no filter means no items

D. Scan returns paginated results; you must handle LastEvaluatedKey to get all items

Solution

1. Step 1: Recognize Scan pagination behavior

   Scan returns results in pages. If the table is large, it returns a subset and a LastEvaluatedKey to continue.

2. Step 2: Identify missing pagination handling

   The code does not check for LastEvaluatedKey or continue scanning, so it only logs the first page.

3. Final Answer:

   Scan returns paginated results; you must handle LastEvaluatedKey to get all items -> Option D

4. Quick Check:

   Scan pagination needs LastEvaluatedKey handling = D [OK]

Hint: Handle LastEvaluatedKey to get all Scan results [OK]

Common Mistakes:

• Assuming Scan returns all items in one call
• Confusing Scan with Query filters
• Using query() instead of scan()

5. You want to find all items where the attribute 'status' equals 'active' in a large DynamoDB table. Why might using Scan be inefficient, and what is a better approach?

hard

A. Scan reads the entire table which is slow; better to use Query with a Global Secondary Index on 'status'

B. Scan only reads matching items quickly; no better approach needed

C. Scan automatically uses indexes; Query is slower for this case

D. Scan updates items with 'status'='active'; Query deletes them

Solution

1. Step 1: Understand Scan inefficiency

   Scan reads every item in the table, which is slow and costly for large tables.

2. Step 2: Use Query with indexes

   Creating a Global Secondary Index on 'status' allows Query to quickly find items where 'status'='active' without scanning all items.

3. Final Answer:

   Scan reads the entire table which is slow; better to use Query with a Global Secondary Index on 'status' -> Option A

4. Quick Check:

   Use Query with index, not Scan for filtering = C [OK]

Hint: Use Query with index, not Scan, for filtered searches [OK]

Common Mistakes:

• Thinking Scan is always fast
• Assuming Scan uses indexes automatically
• Confusing Scan with update or delete operations