Do not mistake a Table Storage RowKey OR filter for indexed point lookups

Source facts

Azure Table Storage has a clustered index on PartitionKey and RowKey. A point lookup specifying both keys is the most efficient documented query form; a range of RowKeys within one PartitionKey is different from scanning that partition.

Microsoft explicitly states that combining RowKey values with OR results in a partition scan, not a range query. Omitting PartitionKey produces a table scan even when the filter includes RowKey. Microsoft Learn.

Applicability

Identify the caller’s actual keys, partition sizes and lookup frequency. Keep this Azure Table Storage behavior separate from a relational database or another service’s indexing model.

DSE recommendation

DSE recommends reviewing the exact generated filter rather than judging efficiency from the small number of requested entities. Compare approved point-lookup or appropriate range designs while preserving the intended result. Consider the application’s write consistency and partitioning requirements before changing its data layout. Do not replace an OR filter with a broad range and silently accept additional entities as equivalent output.

Verification

Use representative populated partitions to compare results, request patterns and observed latency. Include missing keys and boundary values, and reconcile the returned entity IDs. Record the filter and partition context with the measurements. Approve the query design from both correctness and measured behavior, not merely from a successful test against a nearly empty table.

Official references

Microsoft Learn: Design Azure Table storage for queries. Source retrieved September 9, 2026.