Skip to article
Databases Azure Cosmos DB

Cosmos DB spatial index

Cosmos DB spatial index is an indexing-policy entry that helps Cosmos DB for NoSQL query valid GeoJSON points, lines, polygons, and multipolygons efficiently. It makes location-aware queries practical without scanning every item in a container. You see it when applications store coordinates, service areas, delivery zones, device positions, or map features in JSON items. The production check is whether GeoJSON shape, indexed path, query function, and partition strategy all line up. Document the decision in code, templates, metrics, and runbooks.

Source: Microsoft Learn - Microsoft Learn - Cosmos DB spatial index Reviewed 2026-05-13

Exam trap
Assuming the portal, SDK code, and infrastructure template all describe the same current production state.
Production check
Verify the active subscription, resource group, account, database, and container before reading or changing any setting.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
intermediate
CLI mappings
7
Last verified
2026-05-13
Learning paths Graph Databases concept cluster Cosmos DB spatial index
Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

Cosmos DB spatial index matters because location data is often business-critical, but geospatial performance depends on both valid data and the right index policy. If it is ignored, teams can create high-RU queries, slow map screens, incorrect boundary matches, migration surprises, and operations teams that cannot explain why a route query changed cost. Handled well, it gives architects and operators a shared way to connect code behavior, portal settings, CLI output, metrics, and incident runbooks. This is especially important for regulated, multi-tenant, or global workloads where one wrong assumption spreads across users and regions. The practical value is simple: the term turns a database detail into a measurable decision about correctness, cost, latency, recovery, and ownership.

Official wording and source

Cosmos DB spatial index is an indexing-policy entry that helps Cosmos DB for NoSQL query valid GeoJSON points, lines, polygons, and multipolygons efficiently. Microsoft Learn places it in Microsoft Learn - Cosmos DB spatial index; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Cosmos DB spatial index is a spatial index type configured in a container indexing policy for supported GeoJSON objects and spatial query functions. Inspect it through container indexing-policy JSON, Data Explorer, ARM or Bicep templates, SDK container creation code, and query metrics. Validate ST_DISTANCE, ST_WITHIN, and ST_INTERSECTS queries, index policy paths, query metrics, RU charge, item shape, and sample geospatial data. Review GeoJSON validity, indexing scope, partition key, query predicates, composite indexes, migration behavior, and differences from MongoDB geospatial indexes before release.

Exam context

Compare with

Cosmos DB composite index Cosmos DB query Cosmos DB vector index

Where it is used

Where you see it

  1. In the Azure portal, Cosmos DB spatial index appears around account, database, container, metrics, indexing, consistency, networking, or capacity pages where operators confirm current production behavior during releases.
  2. In code and IaC, Cosmos DB spatial index appears as SDK options, resource properties, policy JSON, deployment parameters, query logic, or migration notes that reviewers compare with live resources.
  3. In operations, Cosmos DB spatial index appears beside RU charts, latency, throttling, diagnostics, access failures, restore evidence, cost reviews, and incident tickets during production triage and post-release reviews.
  4. In architecture reviews, Cosmos DB spatial index appears when teams compare Cosmos DB APIs, partition strategy, consistency, retention, capacity mode, and application access patterns.

Common situations

  • Design or review a Cosmos DB workload that depends on spatial index behavior.
  • Troubleshoot latency, throttling, stale reads, indexing, retention, access, recovery, or regional behavior in production.
  • Create architecture, security, or operations evidence for a release, audit, migration, or incident review.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Operational rollout Scenario, objectives, solution, measured impact, and takeaway.
Scenario

BluePeak Energy, a energy organization, ran a meter analytics workload on Azure Cosmos DB. The team used Cosmos DB spatial index to added geospatial filtering to a dispatch platform without full scans while they needed to keep ingestion cost and operational evidence under control.

Goals
  • Improve map-query latency, dispatch accuracy, and RU cost per location search with measurable production evidence
  • Reduce incident triage or release-review effort by at least 30 percent
  • Keep customer-facing P95 latency within the approved service target
  • Document rollback, ownership, and security review steps before rollout
Approach using Cosmos DB spatial index

Architects reviewed the Cosmos DB account, API, database, container, partition key, region layout, and monitoring workbook. The implementation created a spatial index on the location path, validated GeoJSON shape rules, combined spatial predicates with partition filters, and tracked RU charges for distance and boundary queries. Engineers used read-only Azure CLI checks, SDK diagnostics, Azure Monitor metrics, and deployment records to compare intended state with live behavior. The rollout kept one workload, explicit owner tags, rollback steps, and a runbook for safe operator inspection. Security reviewers confirmed least privilege and logging, while developers tested with production-shaped data.

Potential outcomes
  • P95 data-access latency improved by 24 percent during the first production verification window
  • Avoidable RU usage or idle capacity dropped by 18 percent after noisy access patterns were corrected
  • Incident handoff time fell from 50 minutes to 28 minutes because owners, dashboards, and rollback triggers were documented
  • The architecture review could be completed with CLI output, deployment records, and metrics in under one hour
What to learn

Cosmos DB spatial index is valuable when teams connect a Cosmos DB design choice to measurable behavior, ownership, security, cost, and operational proof.

Scenario 02 Production remediation Scenario, objectives, solution, measured impact, and takeaway.
Scenario

MetroLink Media, a media organization, ran a content recommendation service on Azure Cosmos DB. The team used Cosmos DB spatial index to added geospatial filtering to a dispatch platform without full scans while they needed to improve search relevance without a separate data store.

Goals
  • Improve map-query latency, dispatch accuracy, and RU cost per location search with measurable production evidence
  • Reduce incident triage or release-review effort by at least 30 percent
  • Keep customer-facing P95 latency within the approved service target
  • Document rollback, ownership, and security review steps before rollout
Approach using Cosmos DB spatial index

Architects reviewed the Cosmos DB account, API, database, container, partition key, region layout, and monitoring workbook. The implementation created a spatial index on the location path, validated GeoJSON shape rules, combined spatial predicates with partition filters, and tracked RU charges for distance and boundary queries. Engineers used read-only Azure CLI checks, SDK diagnostics, Azure Monitor metrics, and deployment records to compare intended state with live behavior. The rollout kept one workload, explicit owner tags, rollback steps, and a runbook for safe operator inspection. Security reviewers confirmed least privilege and logging, while developers tested with production-shaped data.

Potential outcomes
  • Customer-impacting database alerts fell by 41 percent over the next two release cycles
  • The team reduced manual support checks by 36 percent using repeatable diagnostics and dashboard evidence
  • Monthly Cosmos DB spend moved within 7 percent of the forecast after capacity and query behavior were baselined
  • Auditors accepted the change record because identity scope, monitoring, and rollback evidence were attached
What to learn

Cosmos DB spatial index is valuable when teams connect a Cosmos DB design choice to measurable behavior, ownership, security, cost, and operational proof.

Scenario 03 Scale and governance review Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Silverline Travel, a travel organization, ran a trip-alert and loyalty application on Azure Cosmos DB. The team used Cosmos DB spatial index to added geospatial filtering to a dispatch platform without full scans while they needed to serve bursty mobile traffic during weather events.

Goals
  • Improve map-query latency, dispatch accuracy, and RU cost per location search with measurable production evidence
  • Reduce incident triage or release-review effort by at least 30 percent
  • Keep customer-facing P95 latency within the approved service target
  • Document rollback, ownership, and security review steps before rollout
Approach using Cosmos DB spatial index

Architects reviewed the Cosmos DB account, API, database, container, partition key, region layout, and monitoring workbook. The implementation created a spatial index on the location path, validated GeoJSON shape rules, combined spatial predicates with partition filters, and tracked RU charges for distance and boundary queries. Engineers used read-only Azure CLI checks, SDK diagnostics, Azure Monitor metrics, and deployment records to compare intended state with live behavior. The rollout kept one workload, explicit owner tags, rollback steps, and a runbook for safe operator inspection. Security reviewers confirmed least privilege and logging, while developers tested with production-shaped data.

Potential outcomes
  • Peak-period requests stayed under the approved latency target while throttling remained below 1 percent
  • Developers cut reproduction time for database issues from several hours to less than 40 minutes
  • The product team avoided a duplicate data platform and saved an estimated 22 percent in operating cost
  • Operations gained a reusable checklist for future Cosmos DB releases using the same pattern
What to learn

Cosmos DB spatial index is valuable when teams connect a Cosmos DB design choice to measurable behavior, ownership, security, cost, and operational proof.

Azure CLI

Use CLI to inspect Cosmos DB spatial index consistently across subscriptions, compare live configuration with source-controlled intent, and capture review evidence without changing the JSON engine or runtime.

Useful for

  • Confirm the account, API, database, container, region, and relevant settings before approving a production change involving Cosmos DB spatial index.
  • Export current configuration for pull requests, incident timelines, architecture reviews, audit evidence, and handoff notes.
  • Compare development, staging, and production when latency, RU usage, access, restore, indexing, or networking behavior differs unexpectedly.

Before you run a command

  • Confirm the active tenant, subscription, resource group, Cosmos DB account name, database name, and container or table scope.
  • Start with read-only commands and avoid throughput, indexing, network, key, delete, or deployment changes unless a change ticket approves them.
  • Capture the expected state, owner, business impact, rollback plan, and maintenance window before modifying production resources.

What the output tells you

  • It shows where Cosmos DB spatial index is configured or observed and whether the live resource matches the intended design.
  • It exposes account, database, container, region, policy, throughput, identity, network, or backup details needed for troubleshooting.
  • It creates repeatable evidence that can be pasted into runbooks, incident summaries, audit records, and release reviews.

Mapped commands

Cosmos DB operations

direct 
az cosmosdb list --resource-group <resource-group>
az cosmosdbdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb show --name <account-name> --resource-group <resource-group>
az cosmosdbdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql database list --account-name <account-name> --resource-group <resource-group>
az cosmosdb sql databasediscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql container list --account-name <account-name> --database-name <database-name> --resource-group <resource-group>
az cosmosdb sql containerdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql container show --account-name <account-name> --database-name <database-name> --name <container-name> --resource-group <resource-group>
az cosmosdb sql containerdiscoverDatabases
read-only Microsoft Learn 
az deployment group what-if --resource-group <resource-group> --template-file main.bicep
az deployment groupdiscoverManagement and Governance
read-only Microsoft Learn 
az deployment group create --resource-group <resource-group> --template-file main.bicep
az deployment groupsecureManagement and Governance
mutating Microsoft Learn

Architecture context

Architecturally, Cosmos DB spatial index sits inside the Cosmos DB resource model and influences how application code, platform controls, monitoring, and recovery plans meet. Review it with account topology, API selection, partition strategy, throughput, indexes, consistency, identity, networking, backup mode, and deployment source so the design is understandable before an outage or scale event.

Security
Security for Cosmos DB spatial index starts with knowing who can view data, change configuration, or retrieve operational evidence. Use Microsoft Entra identities, managed identities, scoped Cosmos DB data-plane roles, private endpoints, firewall rules, and monitored deployment pipelines wherever they apply. Avoid exposing account keys, connection strings, session tokens, request payloads, or restored data in logs and tickets. For location data may reveal personal, facility, route, or asset movement information and needs appropriate access controls, document approval requirements before production changes. A secure design records the least-privilege role, owner, logging path, break-glass process, and review cadence so troubleshooting does not become an excuse for broad access.
Cost
Cost for Cosmos DB spatial index shows up through request units, storage, indexing overhead, gateway capacity, replication, backups, or nonproduction copies. Measure RU charge for spatial filters, write overhead from indexing, data retention, map-query fan-out, and inefficient scans before changing the setting or blaming the platform. A cheap configuration for one workload can be expensive for another when traffic patterns, payload size, indexing, consistency, or partition distribution change. Use tags, budgets, and per-resource dashboards so product owners can see which feature drives spend. The strongest cost review connects dollars to a real behavior, such as RU per read, write amplification, retained data, or fan-out queries.
Reliability
Reliability for Cosmos DB spatial index depends on predictable behavior during load spikes, regional events, deployment changes, and dependency failures. Test valid GeoJSON handling, consistent indexing policy deployment, query fallback behavior, and alerts for sudden RU or latency changes with realistic data, SDK retry policies, consistency expectations, and Azure Monitor alerts. Operators should know which symptoms indicate throttling, stale reads, bad indexing, expired data, or network failure. Include restore or rollback steps before changing production resources, because Cosmos DB settings often affect more than one application path. The goal is not only service availability; users need correct data, acceptable latency, and a known recovery path when conditions are messy.
Performance
Performance for Cosmos DB spatial index is measured through latency, RU charge, throttling, query plan, cache behavior, and partition distribution. Review spatial function selectivity, index usage, partition filtering, payload size, continuation tokens, and representative route or boundary tests with production-shaped data instead of tiny development samples. SDK diagnostics, Azure Monitor metrics, query metrics, continuation tokens, and response headers should tell the same story. Tune the design only after separating application delays from Cosmos DB configuration. A good performance fix reduces latency or RU waste without weakening security, correctness, indexing accuracy, or recovery. Re-test after deployments because schema, index, consistency, and traffic changes can shift the result.
Operations
Operations for Cosmos DB spatial index should be repeatable enough that a second engineer can verify the same facts without tribal knowledge. Keep indexed paths, container creation templates, sample spatial queries, data-shape rules, dashboard links, and ownership of geospatial logic documented with deployment source, owner, change history, and dashboard links. Use read-only Azure CLI checks, portal review, SDK diagnostics, and diagnostic logs to compare intended state with live behavior. Runbooks should say what is safe to inspect, what requires approval, and what evidence must be captured before and after a change. Good operations make the term a checked production control, not a hidden implementation choice.

Common mistakes

  • Assuming the portal, SDK code, and infrastructure template all describe the same current production state.
  • Testing Cosmos DB spatial index only with small development data and missing behavior that appears under real distribution or load.
  • Granting broad account permissions just to inspect one setting, troubleshoot one symptom, or run one script.