Query vs Scan

Understanding the cost and performance differences between Query and Scan operations in DynamoDB.

Query vs Scan: The Cost Difference

Query targets specific partitions using a partition key. It only reads matching items.

Scan reads every item in the table, then filters results. You pay for all items examined, not just items returned.

Cost Example

Table with 1,000 items (4 KB each). You want 10 items matching a specific status.

Using Scan:

  • Items examined: 1,000
  • RCUs consumed: 500
  • Items returned: 10
  • Paid for 1,000 items, got 10

Using Query with GSI on status:

  • Items examined: 10
  • RCUs consumed: 5
  • Items returned: 10
  • Paid for 10 items, got 10

Cost difference: 100x more expensive with Scan

Note: This example uses eventually consistent reads (default). Strongly consistent reads would consume 1,000 RCUs for Scan and 10 RCUs for Query.

As tables grow, this gap widens. A 5 million row table could cost $625/month with Scan vs $0.006/month with Query for the same data access.

Note: This is an extreme case used to illustrate the importance of designing for Query operations. While real-world scenarios vary, the fundamental principle remains: Scan operations become exponentially more expensive as your table grows.

When to Use Each

Use Query for:

  • Production request paths
  • Known partition key values
  • Any frequent access pattern

Use Scan only for:

  • Small tables (<100 items)
  • One-time admin tasks during off-hours

Even with ProjectionExpression to return fewer attributes, you pay RCUs for the full item size examined.

How to Avoid Scans

Design your schema around access patterns before building your table:

  1. Identify access patterns - What queries will you run most often? What attributes do you filter by?

  2. Design base table for primary access pattern - Partition key should be the attribute you query most frequently

  3. Create GSIs for additional access patterns - Each GSI reorganizes data with a different partition key. See Global Secondary Indexes (GSI). Consider multi-attribute keys for complex queries - See Multi-Attribute Keys

  4. Use LSIs for alternate sort orders - Same partition key as base table, different sort key. See Local Secondary Indexes (LSI)

Key Takeaways

  • Query reads only matching items; Scan reads everything then filters
  • You pay for items examined, not items returned
  • Design tables and indexes to enable Query operations
  • Understanding access patterns before building your schema is critical
  • Never use Scan in production request paths

Resources