--- title: The Cosmos DB Query That Burned 2 Million RUs Before Lunch description: A real-world postmortem of a Cosmos DB query that consumed ~2 million Request Units before noon. The culprit was a three-line query combining SELECT *, no... canonical: https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Cosmos DB Query That Burned 2 Million RUs Before Lunch | daily.dev og:description: A real-world postmortem of a Cosmos DB query that consumed ~2 million Request Units before noon. The culprit was a three-line query combining SELECT *, no... og:url: https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso og:image: https://api.daily.dev/og/posts/3v2BNWPso.png og:image:alt: The Cosmos DB Query That Burned 2 Million RUs Before Lunch og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Cosmos DB Query That Burned 2 Million RUs Before Lunch **[Medium](https://daily.dev/sources/medium_js)** · 6 min read · 9 upvotes · 2 comments ## Summary A real-world postmortem of a Cosmos DB query that consumed ~2 million Request Units before noon. The culprit was a three-line query combining SELECT *, no partition key filter, and an ORDER BY — causing a cross-partition fan-out across 4 million documents. Compounded by a dashboard polling every 30 seconds across 40 browser tabs, it triggered a throttling storm of 429 errors. The fix involved three changes: filtering on the partition key to eliminate fan-out, projecting only needed fields instead of SELECT *, and replacing polling with the Cosmos DB change feed plus caching. RU cost dropped from thousands per call to single digits. The post also explains when adding more RUs is appropriate versus when it just papers over a bad query, and provides a practical audit checklist for Cosmos deployments. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does a Cosmos DB query that works fine in development become extremely expensive in production? It happens when the query lacks a filter on the partition key, forcing Cosmos DB to fan out across every physical partition instead of targeting one. In development with a small dataset on a single partition this is invisible, but at scale (millions of documents across dozens of partitions), the same query scans and sorts everything, consuming Request Units proportional to the number of partitions touched. _daily.dev surfaces practical war stories like this for developers tuning Cosmos DB costs before they scale._ ### How can I reduce Request Unit consumption on a Cosmos DB query that scans across partitions? Filter the WHERE clause on the partition key so the query hits a single partition instead of fanning out to all of them, project only the specific fields needed instead of using SELECT *, and avoid re-running the same expensive query on a tight polling interval by switching to the change feed and caching shared results across clients. One team dropped RU cost per call from thousands to single digits this way. _developers optimizing database costs can find hands-on fixes like these while researching Cosmos DB on daily.dev._ ### Should I raise Cosmos DB provisioned RU/s when I'm seeing 429 throttling errors? Not necessarily; check Normalized RU Consumption first. If overall RU usage is under budget but requests are still throttled, a single hot partition or a cross-partition scan is the real problem, and adding more throughput just pays for the underlying bug without fixing it. Only raise RU/s when consumption is genuinely high due to well-distributed demand, where 1-5% throttled requests is considered healthy. _engineers debugging throttling versus real capacity limits can track patterns like this through daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 0 upvotes > That 30-second poll across 40 tabs is a proper multiplier. Partition-key filters and field projection fix the query, but moving the dashboard to change feed plus caching is what stops the same problem coming back. ## Similar posts on daily.dev - [Our billing pipeline was suddenly slow. The culprit was a hidden bottleneck in ClickHouse](https://daily.dev/posts/our-billing-pipeline-was-suddenly-slow-the-culprit-was-a-hidden-bottleneck-in-clickhouse-t6saatu35) · Cloudflare · 7 upvotes · 0 comments - [Cloudflare Identifies Query Planning Bottleneck in ClickHouse](https://daily.dev/posts/cloudflare-identifies-query-planning-bottleneck-in-clickhouse-2yvq0qcqd) · InfoQ · 0 upvotes · 0 comments - [A Guide to Query Performance](https://daily.dev/posts/a-guide-to-query-performance-q5avubs2p) · DevBlogs · 1 upvotes · 0 comments --- Tags: [#backend](https://daily.dev/tags/backend), [#cosmos-db](https://daily.dev/tags/cosmos-db) [View this post on daily.dev](https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Cosmos DB Query That Burned 2 Million RUs Before Lunch","url":"https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso"},"datePublished":"2026-07-18T00:11:09.267Z","dateModified":"2026-09-14T07:49:15.028Z","description":"A real-world postmortem of a Cosmos DB query that consumed ~2 million Request Units before noon. The culprit was a three-line query combining SELECT *, no...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/305d7ac598a98487953ca62abd9c2321?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/305d7ac598a98487953ca62abd9c2321?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":9},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"backend,cosmos-db","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"The Cosmos DB Query That Burned 2 Million RUs Before Lunch"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso","comment":[{"@type":"Comment","text":"That 30-second poll across 40 tabs is a proper multiplier. Partition-key filters and field projection fix the query, but moving the dashboard to change feed plus caching is what stops the same problem coming back.","datePublished":"2026-07-18T03:51:20.072Z","url":"https://daily.dev/posts/3v2BNWPso#c-mm2FZw1rk","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-cosmos-db-query-that-burned-2-million-rus-before-lunch-3v2bnwpso#faq","mainEntity":[{"@type":"Question","name":"Why does a Cosmos DB query that works fine in development become extremely expensive in production?","acceptedAnswer":{"@type":"Answer","text":"It happens when the query lacks a filter on the partition key, forcing Cosmos DB to fan out across every physical partition instead of targeting one. In development with a small dataset on a single partition this is invisible, but at scale (millions of documents across dozens of partitions), the same query scans and sorts everything, consuming Request Units proportional to the number of partitions touched. daily.dev surfaces practical war stories like this for developers tuning Cosmos DB costs before they scale."}},{"@type":"Question","name":"How can I reduce Request Unit consumption on a Cosmos DB query that scans across partitions?","acceptedAnswer":{"@type":"Answer","text":"Filter the WHERE clause on the partition key so the query hits a single partition instead of fanning out to all of them, project only the specific fields needed instead of using SELECT *, and avoid re-running the same expensive query on a tight polling interval by switching to the change feed and caching shared results across clients. One team dropped RU cost per call from thousands to single digits this way. developers optimizing database costs can find hands-on fixes like these while researching Cosmos DB on daily.dev."}},{"@type":"Question","name":"Should I raise Cosmos DB provisioned RU/s when I'm seeing 429 throttling errors?","acceptedAnswer":{"@type":"Answer","text":"Not necessarily; check Normalized RU Consumption first. If overall RU usage is under budget but requests are still throttled, a single hot partition or a cross-partition scan is the real problem, and adding more throughput just pays for the underlying bug without fixing it. Only raise RU/s when consumption is genuinely high due to well-distributed demand, where 1-5% throttled requests is considered healthy. engineers debugging throttling versus real capacity limits can track patterns like this through daily.dev."}}]} ```