IntelligentHQ
IntelligentHQ
Skip to content
Cloud service Databases

Azure Cosmos DB

Azure Cosmos DB is a fully managed NoSQL and vector database for applications that need low latency, elastic scale and global distribution. It offers multi-region writes with a 99.999% availability SLA, built-in vector and hybrid search, and serverless or provisioned throughput billed in request units.1

Also known as Azure Cosmos DB for NoSQL

Intended for
Application developers, Cloud architects, AI and agent developers, Database and platform operators
Runs on
Azure regions, single or multi-region, Serverless or provisioned throughput, Cosmos DB in Microsoft Fabric, Local emulator for development
Official Microsoft product page (opens in a new tab) Official documentation (opens in a new tab)

At a glance

What is it?
Azure Cosmos DB is Microsoft's fully managed NoSQL and vector database. It holds document, key-value, graph, table and vector data, indexes everything automatically by default, and scales throughput and storage independently in any Azure region. Microsoft recommends the native API for NoSQL for most new applications. Azure DocumentDB, the vCore MongoDB-compatible service formerly called Azure Cosmos DB for MongoDB (vCore), is now a separate product built on the open source DocumentDB engine on PostgreSQL. Cosmos DB in Microsoft Fabric uses the same engine and infrastructure as Azure Cosmos DB for NoSQL.123
What does it do?
Cosmos DB answers reads and writes with single-digit millisecond response times, replicates data to the Azure regions you choose with automatic failover and optional multi-region writes, and emits a change feed for event-driven processing. It offers vector search with DiskANN, full-text and hybrid search for retrieval-augmented generation, AI agents and LLM caching, hierarchical partition keys for multitenant apps, continuous backup with point-in-time restore, and no-ETL analytics through Fabric mirroring or Azure Synapse Link. Foundry Agent Service's standard setup stores agent threads in the customer's own Cosmos DB for NoSQL account.14
Who needs it?
Developers building always-on or internet-scale applications such as online retail, IoT telemetry, gaming, personalization and booking systems, and teams building AI agents that need conversation history and vectors next to operational data. Microsoft lists flexible-schema, latency-sensitive, highly elastic, high-throughput and mission-critical workloads as good fits.1
What does it need?1
  • An Azure subscription, or the lifetime free tier, the local emulator or the Azure free account
  • A partition key design for each container
  • A throughput model: provisioned (manual or autoscale) or serverless
  • An SDK for your language (.NET, Java, JavaScript or Node.js, Python, Go or Rust)
  • For agent thread storage in Foundry Agent Service: at least 3,000 RU/s on the account
What it is not
Cosmos DB is not an analytics database: Microsoft calls it a poor fit for OLAP workloads and points to Microsoft Fabric. Microsoft also calls it a poor fit for highly relational apps, where it suggests Azure SQL or Azure Database for MySQL. Azure DocumentDB (formerly Cosmos DB for MongoDB vCore) is a different service with a scale-up vCore model and a 99.995% SLA. The 99.999% availability figure applies to multi-region accounts, not to every deployment.1

Availability and licensing. Generally available. The lifetime free tier gives 1,000 RU/s and 25 GB of storage per account; Microsoft states reserved capacity discounts of up to 63% (checked 26 Oct 2026). Multi-region accounts carry a 99.999% availability SLA. At Ignite 2025 Azure DocumentDB, previously Azure Cosmos DB for MongoDB (vCore), became generally available as a separate product with up to 99.995% availability, and Cosmos DB in Fabric became generally available as part of Microsoft Fabric databases.25

The problem it solves

Applications with users on several continents, sudden traffic spikes or AI features need a database that answers in milliseconds near each user, scales without downtime and keeps vectors next to the data they describe. Running separate caches, document stores and vector databases adds integration work and consistency problems.

Cosmos DB replicates data to the regions you choose, scales request-unit throughput or runs serverless, offers tunable consistency, and indexes vectors with DiskANN alongside the documents.1

How it works

  • Account and regions: you add Azure regions, choose single or multi-region writes and set a consistency level; Strong consistency gives a recovery point objective of zero.
  • Databases and containers: containers hold JSON items and are partitioned by a partition key, optionally hierarchical.
  • Throughput: provisioned RU/s (manual or autoscale) or serverless; reserved capacity discounts are available.
  • Indexing and search: automatic indexing plus vector (DiskANN), full-text (BM25) and hybrid search.
  • Change feed and analytics: change feed for Azure Functions or Spark, and Fabric mirroring or Synapse Link for analytics without ETL.15
Azure Cosmos DB architecture: components by layer and how they connectCopilot & businessappsAgents & automationAI models & platformData & analyticsCloud & hybridinfrastructureApplication, AI agent or Azure Functions: Reads and writes items through SDKsApplication, AI agent orAzure FunctionsFoundry Agent Service (standard setup): Stores agent threads and metadata in your accountFoundry Agent Service(standard setup)Automatic, vector (DiskANN) and full-text indexes: Serve point reads, queries and similarity searchAutomatic, vector (DiskANN)and full-text indexesDatabases and partitioned containers: Store JSON items, scaled by partition key and throughputDatabases and partitionedcontainersChange feed: Streams changes to event-driven consumersChange feedFabric mirroring or Synapse Link: Near real-time analytics without ETLFabric mirroring or SynapseLinkCosmos DB account (regions and consistency): Replication, failover and consistency settingsCosmos DB account (regionsand consistency)
Diagram as a list

  1. Copilot & business apps

    • Application, AI agent or Azure FunctionsReads and writes items through SDKsConnects to Cosmos DB account (regions and consistency)

  2. Agents & automation

    • Foundry Agent Service (standard setup)Stores agent threads and metadata in your accountConnects to Databases and partitioned containers

  3. AI models & platform

    • Automatic, vector (DiskANN) and full-text indexesServe point reads, queries and similarity search

  4. Data & analytics

    • Databases and partitioned containersStore JSON items, scaled by partition key and throughputConnects to Automatic, vector (DiskANN) and full-text indexes
    • Change feedStreams changes to event-driven consumers
    • Fabric mirroring or Synapse LinkNear real-time analytics without ETLConnects to Databases and partitioned containers

  5. Cloud & hybrid infrastructure

    • Cosmos DB account (regions and consistency)Replication, failover and consistency settingsConnects to Databases and partitioned containers
Components and connections as documented by Microsoft.

Capabilities

  • Global distribution with SLA-backed availability15

    Turnkey replication to any Azure region, multi-region writes and automatic failover, with a 99.999% availability SLA for multi-region accounts and a latency SLA.

    Why it matters: Keeps customer-facing apps online and fast for users in several regions.

    Limits: The 99.999% figure needs a multi-region setup; zero data loss on failover (RPO 0) requires Strong consistency.

  • Vector, full-text and hybrid search15

    Vector indexing and search with DiskANN, full-text search (BM25) and hybrid search with semantic ranking, stored with operational data.

    Why it matters: RAG and agent apps can retrieve context from the same database that holds the application data.

    Limits: Search quality depends on the embeddings and chunking you choose.

  • Elastic throughput models1

    Provisioned throughput with manual or autoscale request units, or serverless consumption for spiky workloads.

    Why it matters: Capacity follows demand, from prototypes to large production loads.

    Limits: Request unit costs need governance; Microsoft states reserved capacity discounts of up to 63%.

  • Change feed and no-ETL analytics1

    A change feed (latest version and all versions with deletes) for Azure Functions or Spark, and mirroring to Microsoft Fabric or Azure Synapse Link for analytics.

    Why it matters: Event-driven processing and near real-time reporting without extra pipelines.

    Limits: Analytics run outside Cosmos DB; Microsoft calls OLAP workloads a poor fit for the database itself.

  • Thread storage for Foundry agents4

    Foundry Agent Service standard setup keeps messages, conversation history and agent metadata in the customer's own Cosmos DB for NoSQL account.

    Why it matters: Agent data stays in your tenant for data residency and compliance.

    Limits: The account needs at least 3,000 RU/s, and the classic and new agent runtimes use different containers.

  • Cosmos DB in Microsoft Fabric23

    A Fabric-native database on the same engine as Azure Cosmos DB for NoSQL, with data made available in OneLake in Delta Parquet format.

    Why it matters: Teams that build on Fabric can add a NoSQL operational store without managing a separate Azure resource.

    Limits: Billed and governed through Fabric, so it suits Fabric-centric teams more than standalone apps.

Practical use cases

An online retailer needs fast carts and catalogs for shoppers on several continents, with no downtime at peak sales.
Approach
Use Cosmos DB for NoSQL with multi-region writes, autoscale throughput and partition keys designed around customer or tenant.
Role of Azure Cosmos DB
Cosmos DB is the operational store close to each user group.
Data, infrastructure and skills
A partition key design, chosen regions and a throughput budget.
Type of benefit
Availability and responsiveness
Caveats
Multi-region writes need conflict handling; request unit costs must be monitored.
First step
Model the cart container on the emulator and load-test its partition key.
An enterprise building agents in Microsoft Foundry must keep conversation data in its own tenant.
Approach
Use Foundry Agent Service standard setup with a customer-owned Cosmos DB for NoSQL account for threads.
Role of Azure Cosmos DB
Cosmos DB stores messages, conversation history and agent metadata.
Data, infrastructure and skills
A Cosmos DB for NoSQL account with at least 3,000 RU/s, plus Azure Storage and Azure AI Search.
Type of benefit
Data control and compliance
Caveats
Capability settings cannot be changed on an existing project; plan resources before creating it.
First step
Provision the standard agent setup in a test subscription with the Bicep template.
A support app needs answers grounded in product documents and recent tickets.
Approach
Store chunked documents and embeddings in Cosmos DB and use vector or hybrid search to retrieve context for the model.
Role of Azure Cosmos DB
Cosmos DB serves both operational data and retrieval.
Data, infrastructure and skills
An embedding model and a vector indexing policy on the container.
Type of benefit
Simpler RAG architecture
Caveats
Retrieval quality depends on chunking and embeddings; test hybrid against pure vector search.
First step
Index a sample of documents with a vector policy and compare search results.

Who uses it

Works with

Optional integration

Alternative approaches

  • Azure SQLMicrosoft suggests Azure SQL for highly relational apps.

Optional integration for

Relationship labels follow Microsoft's documentation. "Alternative approaches" does not mean one is better: each profile says when it fits.

Compared with

Getting started

  1. Start free

    Use the emulator locally, or create an account with the lifetime free tier (1,000 RU/s and 25 GB).

    Check: You can create a database and a container and write a test item.

  2. Choose API and capacity mode

    Pick the API for NoSQL unless you need another API, and choose serverless or provisioned throughput.

    Check: The account shows the chosen API and capacity mode.

  3. Design partitions

    Choose a partition key (or hierarchical keys) that spreads reads and writes evenly.

    Check: No single logical partition dominates request units in metrics.

  4. Add search

    Define a vector policy and index for embeddings, and full-text indexing if you need hybrid search.

    Check: A similarity query returns ranked results.

  5. Connect analytics

    Enable mirroring into Microsoft Fabric for reporting on the operational data.

    Check: Cosmos DB tables appear in a Fabric mirrored database.

Official resources

Deciding whether you need it?

Three free tools apply Microsoft's own published guidance to your situation, and say when Azure Cosmos DB or any new technology is not needed.

Sources

Each statement above links to the source it comes from. Labels say who reported it.

  1. Azure Cosmos DB overview (Unified AI Database) (opens in a new tab) Microsoft · Vendor-reported
  2. Microsoft Ignite 2025 Book of News (opens in a new tab) Microsoft · Vendor-reported · link checked 27 Oct 2026
  3. Cosmos DB in Microsoft Fabric (opens in a new tab) Microsoft · Vendor-reported
  4. Set up standard agent resources for Foundry Agent Service (opens in a new tab) Microsoft · Vendor-reported
  5. Azure Cosmos DB product page (opens in a new tab) Microsoft · Vendor-reported · link checked 27 Oct 2026

Fill out the form below to request your copy.

Name(Required)