How does indexing work in Azure Cosmos DB?

By default, Cosmos DB automatically indexes every property in every JSON item you insert — no schema definition, no CREATE INDEX statement required. This is called the automatic indexing policy. When you write a document, the indexing engine traverses the JSON tree and adds every field path, array element, and nested object to a set of inverted indexes maintained alongside the data. This is why write costs in Cosmos DB are higher than read costs per RU — every write triggers index updates.

The indexing policy is configured per container in JSON and controls three things:

1. indexingMode — consistent (default, synchronous), lazy (asynchronous, lower write cost, not recommended), or none (disables indexing entirely).
2. includedPaths — Explicit paths to index (e.g., /address/city/?). Wildcard /* indexes everything.
3. excludedPaths — Paths to exclude from indexing (e.g., large text fields you never filter on). Excluding high-cardinality or rarely-queried large fields significantly reduces RU cost per write and storage overhead.

Three index types exist:

• Range index — Default for scalar values. Supports =, <, >, BETWEEN, and ORDER BY.
• Spatial index — For GeoJSON geometry types. Supports ST_DISTANCE, ST_INTERSECTS, and other geo queries.
• Composite index — Required when an ORDER BY clause references two or more properties, or when a filter and ORDER BY target different properties. You must explicitly define composite indexes.

A common optimization: exclude the /_etag path and any large blob-like string fields from indexing by default to reduce write RU consumption on write-heavy containers.