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

> Combining selected RowKey values with OR produces a partition scan rather than a range query.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:26:59+00:00
- Modified: 2026-09-10T01:23:49+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Combining selected RowKey values with OR produces a partition scan rather than a range query.

## Potentially affected

Azure Table Storage applications designing high-volume entity lookups.

## DSE recommendation

Classify the actual key filter and test equivalent lookup designs before accepting a high-volume query.

## Article

## 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](https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-for-query).

## 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](https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-for-query). Source retrieved September 9, 2026.

## Primary reference

- Name: Design Azure Table storage for queries | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-for-query
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not mistake a Table Storage RowKey OR filter for indexed point lookups,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.