Why should you avoid Scan operations in DynamoDB?
Learn why DynamoDB Scan is slow and costly, how filters still consume capacity, and how Query plus GSIs/LSIs give fast, cheap, scalable access.
Expected Interview Answer
You should avoid Scan because it reads every item in a table (or index) and consumes read capacity for all of them before filtering, making it slow, expensive, and non-scalable compared to Query or GetItem which target specific partition keys.
A Scan walks the entire table across all partitions, and any FilterExpression is applied AFTER the data is read, so you still pay for the scanned items even if the filter discards them. As data grows, Scan latency and cost grow linearly and can throttle other traffic by exhausting provisioned capacity. The right pattern is to design keys and Global/Local Secondary Indexes so that access happens through Query on a known partition key, reserving Scan for rare full-table jobs like exports or one-off migrations.
- Query and GetItem stay fast at any table size
- Read capacity is spent only on items you actually need
- Avoids throttling other workloads on the table
- Predictable, low latency for user-facing paths
- Lower cost, especially on large tables
AI Mentor Explanation
Finding one player's score by reading every single ball in a 50-over scorebook, page by page, is Scan. Even if you only want Kohli's runs, you flip through all 300 deliveries first, then discard the rest. A Query is like turning straight to Kohli's own summary row in the batting card, indexed by name, and reading only his numbers.
Step-by-Step Explanation
Step 1
Understand what Scan does
Scan reads every item in the table or index and consumes capacity for all of them before any filter runs.
Step 2
See why filters don't save cost
A FilterExpression is applied after the read, so scanned-but-discarded items still count against read capacity units.
Step 3
Model your access patterns
List the queries your app actually needs and design partition/sort keys so each one maps to a targeted lookup.
Step 4
Add secondary indexes
Create GSIs or LSIs so alternate access patterns become Query operations on a known key instead of Scans.
Step 5
Reserve Scan for batch jobs
Use Scan only for rare full-table work like exports or migrations, ideally with parallel segments and rate limiting.
What Interviewer Expects
- Knows Scan reads the whole table and Query targets a partition key
- Understands filters run after the read and still cost capacity
- Can explain cost and latency scaling with table size
- Knows GSIs/LSIs turn Scans into Queries
- Recognizes legitimate uses of Scan (exports, migrations)
Common Mistakes
- Thinking a FilterExpression reduces consumed read capacity
- Believing Scan is fine because it 'works' on small tables
- Not designing indexes for known access patterns
- Confusing Scan with Query in when each is appropriate
- Running unthrottled parallel Scans that starve production traffic
Best Answer (HR Friendly)
“A Scan makes DynamoDB read the entire table just to find a few items, which gets slow and costly as data grows. It's better to design the keys and indexes so the database can jump straight to the records you want, saving both time and money.”
Code Example
// Reads EVERY item, then filters — pays for all of them
const bad = await client.send(new ScanCommand({
TableName: 'Orders',
FilterExpression: 'customerId = :c',
ExpressionAttributeValues: { ':c': { S: 'CUST#123' } },
}))// Reads only this customer's items via the key
const good = await client.send(new QueryCommand({
TableName: 'Orders',
KeyConditionExpression: 'customerId = :c',
ExpressionAttributeValues: { ':c': { S: 'CUST#123' } },
}))Follow-up Questions
- When is a Scan genuinely the right choice?
- How does a parallel Scan work and when would you use it?
- How do GSIs and LSIs help you avoid Scans?
- What is the difference between a FilterExpression and a KeyConditionExpression?
- How does DynamoDB pagination with LastEvaluatedKey work during a Scan?
MCQ Practice
1. When does a DynamoDB FilterExpression on a Scan reduce consumed read capacity?
Filters are applied after items are read, so consumed capacity reflects all scanned items regardless of the filter.
2. Which operation is most efficient for retrieving all items with a known partition key?
Query targets a specific partition key and reads only matching items, unlike Scan which reads the whole table.
3. A legitimate use of Scan is:
Scan suits rare full-table jobs like exports or migrations; targeted lookups should use Query or GetItem.
Flash Cards
What does a Scan read? — Every item in the table or index, consuming capacity for all of them before any filter is applied.
When is a filter applied in a Scan? — After items are read, so filtered-out items still consume read capacity units.
How do you avoid Scans? — Model access patterns and add GSIs/LSIs so lookups become Query operations on a known key.
When is Scan acceptable? — Rare full-table jobs like exports or migrations, ideally with parallel segments and rate limiting.