Great question! It’s easy to write off Scan as the "slow, inefficient cousin" of Query, but there are actually several scenarios where it’s not just acceptable—it’s the right tool for the job. Let me walk you through the most common use cases with real-world examples:

• No usable partition/sort key for Query
  Suppose you have a user table with user_id as the partition key, and you need to find all users who haven’t logged in in the last 30 days. Since this filter condition doesn’t tie to the partition or sort key, Query can’t help here (unless you’ve built a secondary index specifically for login dates, which might not be worth the overhead for a rare task). A Scan with a FilterExpression checking the last_login timestamp is the straightforward solution—especially if this is a daily batch job run during off-peak hours.

• Full-table data exports or migrations
  If you need to move all your DynamoDB data to S3 for offline analytics, or migrate it to another database or environment, Scan is purpose-built for this. It natively supports pagination via LastEvaluatedKey, so you can batch read records without overwhelming your system. Query can’t retrieve every record across all partitions, making Scan the only viable option here.

• Low-frequency queries on small tables
  For tiny tables (think thousands of records or fewer), the performance gap between Scan and Query is negligible. Let’s say you have a config table with 500 system settings, and you need to find all disabled configurations. Building a secondary index just for this rare query would add unnecessary maintenance costs. A Scan here is fast, simple, and far more cost-effective.

• Complex cross-partition filtering
  Imagine you have an orders table partitioned by region, with order_date as the sort key. If you need to find all orders over $1000 placed by customers in the healthcare industry (and industry isn’t indexed), Query can only target one region at a time. A Scan with a FilterExpression checking both order_amount and customer_industry lets you retrieve all matching records across every partition in one go—perfect for ad-hoc analysis that doesn’t need sub-second latency.

• Data validation or compliance audits
  When you need to verify every record in your table (e.g., checking that all email fields follow a valid format, or auditing for compliance with data regulations), Scan is the only way to go. Query can’t cover every entry, so you’ll rely on Scan to iterate through the entire dataset and apply your validation logic.

Quick Optimization Tips for Scan #

Even when using Scan, you can keep it efficient:

• Use ProjectionExpression to only fetch the fields you need (reduces data transfer).
• Leverage pagination with Limit and LastEvaluatedKey to avoid large single-request payloads.
• Schedule Scan jobs during low-traffic periods to minimize impact on production workloads.

内容的提问来源于stack exchange，提问作者user3056266