Can a custom indexing policy reduce request-unit costs while preserving range-query performance in Cosmos DB?

Short answer

Yes. A custom indexing policy that excludes genuinely unused paths reduces write request-unit (RU) charges, because Cosmos DB no longer maintains index entries for those paths on every insert or update. Range-query performance is preserved as long as every path you filter or sort on with >, <, >=, <=, or ORDER BY keeps a Range index. The risk is not the policy itself but accidentally excluding a path a query depends on, and underestimating the background index transformation that follows the change.

What is confirmed behavior

With the default automatic policy, Cosmos DB indexes every scalar property, and each indexed property adds to the per-write RU charge. Switching the indexing mode to consistent with an explicit excludedPaths list (typically /unusedSection/* style wildcards) removes that per-write cost for the excluded subtrees. Equality filters (=, IN, ARRAY_CONTAINS) work with either Hash or Range indexes, so keeping a Range index on your hot equality fields preserves their performance and future-proofs them for range use.

The important caveat: composite indexes do not substitute for single-path range indexes. The default policy's wildcard composite entry supports ORDER BY patterns, but a simple range predicate on one field needs a Range index on that field. If you exclude a path that a range query uses, the query still returns correct results but falls back to a scan — RU consumption and latency climb sharply.

Index transformation realities

Applying a new policy triggers an asynchronous background rebuild. Writes are not blocked, but queries that depend on newly added indexes may return incomplete results until the transformation finishes. There is no incremental or phased API for this; your only levers are:

• Temporarily raising provisioned RU/s so the background work completes faster without starving user traffic.
• Scheduling the change during a low-traffic window, especially on serverless accounts where transformation work shares the request budget.
• Planning for hours to days on containers holding hundreds of GB or more.

Also note: re-including a path you excluded earlier triggers another full transformation with the same cost, so exclude conservatively.

How to verify it worked

1. Policy check: In the portal, open the container → Scale & Settings → Indexing Policy, and confirm excluded paths and index kinds match your design.
2. Transformation progress: Poll the container resource (ReadContainerAsync in the SDK, or REST GET on the collection) and watch indexTransformationProgress until it reaches 100%. This is not an Azure Monitor metric, so alerting requires custom polling.
3. Query behavior: Run a representative range query with query metrics enabled. Healthy index usage shows high index utilization and retrievedDocumentCount close to outputDocumentCount. A large retrieved-to-output ratio means you are scanning.
4. Write cost: Compare the x-ms-request-charge header on create/replace operations before and after; the reduction should track the number of excluded indexed paths.
5. Headroom: Monitor Normalized RU Consumption during the transformation to confirm user traffic keeps capacity.

Recommendation

Exclude only paths you are confident no query filters, sorts, or joins on — audit your query workload first using diagnostic logs or SDK query text capture. Keep Range indexes on everything queried, add composite indexes only for multi-field ORDER BY or multi-predicate queries, and treat the transformation as a maintenance event with monitoring, not a fire-and-forget change. Behavior described reflects the NoSQL API's long-standing indexing model; if you are on a recently released SDK or serverless tier, re-verify transformation progress fields against current documentation before relying on them in automation.