{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/", "slug": "dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups", "url": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/" }, "title": "Do not mistake a Table Storage RowKey OR filter for indexed point lookups", "summary": "Combining selected RowKey values with OR produces a partition scan rather than a range query.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:26:59+00:00", "modified_at": "2026-09-10T01:23:49+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 229, "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.", "primary_source": { "name": "Design Azure Table storage for queries | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-for-query", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

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.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

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

", "content_text": "Source facts\nAzure 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.\nMicrosoft 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.\nApplicability\nIdentify 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.\nDSE recommendation\nDSE 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.\nVerification\nUse 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.\nOfficial references\nMicrosoft Learn: Design Azure Table storage for queries. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nAzure 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.\n\nMicrosoft 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).\n\n## Applicability\n\nIdentify 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nUse 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.\n\n## Official references\n\n[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." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/", "url": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Do not mistake a Table Storage RowKey OR filter for indexed point lookups", "item": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/", "url": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/", "headline": "Do not mistake a Table Storage RowKey OR filter for indexed point lookups", "description": "Combining selected RowKey values with OR produces a partition scan rather than a range query.", "abstract": "Combining selected RowKey values with OR produces a partition scan rather than a range query.", "articleBody": "Source facts\nAzure 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.\nMicrosoft 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.\nApplicability\nIdentify 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.\nDSE recommendation\nDSE 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.\nVerification\nUse 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.\nOfficial references\nMicrosoft Learn: Design Azure Table storage for queries. Source retrieved September 9, 2026.", "datePublished": "2026-09-10T00:26:59+00:00", "dateModified": "2026-09-10T01:23:49+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-297-do-not-mistake-a-table-storage-rowkey-or-filter-for-indexed-point-lookups/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Do not mistake a Table Storage RowKey OR filter for indexed point lookups" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 229, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Design Azure Table storage for queries | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-for-query" } } ] } }