Azure Cosmos DB

About Azure Cosmos DB

Azure Cosmos DB is Microsoft Azure's fully managed distributed database service for applications that need low-latency access, elastic horizontal scaling and global distribution. The service is strongest for high-scale operational workloads that fit its distributed data model and can be designed around partitioning, request-unit economics and a deliberate consistency choice. Buyers should not treat Cosmos DB as a generic replacement for every relational database: the application architecture, API model, partition key and access patterns materially affect performance, cost and operational fit.

What is Azure Cosmos DB used for?

Azure Cosmos DB is designed for modern applications that need to serve data quickly across large scale or across multiple geographic regions. Common scenarios include gaming, e-commerce, IoT ingestion, personalization, user profiles, event-driven applications, catalog data, session data and AI applications that need flexible JSON documents, vector search or globally distributed data access.

Microsoft positions Cosmos DB as a distributed NoSQL engine with automatic indexing, elastic horizontal scale and multi-region replication. That makes it useful when an application needs to grow beyond one database server or serve users from several regions. It is less appropriate when the primary requirement is complex relational reporting, heavy cross-table joins or SQL Server instance compatibility, because those workloads may fit Azure SQL Database or another relational service better.

Which APIs and data models does Azure Cosmos DB support?

Microsoft currently documents Azure Cosmos DB APIs for NoSQL, MongoDB, Apache Cassandra, Apache Gremlin and Table for request-unit based accounts. These APIs provide different developer interfaces over the Cosmos DB distributed platform, while the exact feature set and compatibility details vary by API. Microsoft also offers separate vCore-based services under the Cosmos DB pricing umbrella for scenarios such as MongoDB vCore and PostgreSQL.

Choosing the API is an architectural decision, not a cosmetic setting. Teams should verify the wire protocol, driver compatibility, indexing behavior, transaction model, migration requirements and features they depend on before creating the account. Microsoft states that the compute pricing model and API selected for a Cosmos DB account cannot simply be changed afterward, so buyers should avoid creating production accounts before confirming the application model.

How do request units, provisioned throughput, autoscale and serverless work?

For the main request-unit based APIs, Azure Cosmos DB measures database work in Request Units. Reads, writes, updates and queries consume RU according to the CPU, memory and I/O required. Standard provisioned throughput reserves a configured amount of RU per second and bills for that provisioned capacity. Autoscale provisioned throughput lets a database or container scale within a configured maximum and bills according to the highest throughput used during each hour.

Serverless removes the need to pre-provision RU/s and charges for request units actually consumed. Microsoft positions serverless for intermittent or unpredictable workloads with lower average utilization, while provisioned throughput is better for sustained traffic and workloads that need predictable performance. Serverless also has architectural differences: Microsoft documents single-region operation for serverless, whereas provisioned throughput supports global distribution across multiple Azure regions.

How does Azure Cosmos DB pricing work?

Azure Cosmos DB does not have one fixed monthly price. Microsoft currently bills across compute, storage and bandwidth, with the compute meter depending on the chosen model. Request-unit accounts can use standard provisioned throughput, autoscale provisioned throughput or serverless. Storage is billed for consumed data and indexes, and replicated regions can multiply both throughput and storage charges. Cross-region replication and outbound data transfer can also add cost.

Microsoft's current pricing page says new eligible accounts can use a free tier that includes 1,000 RU/s of provisioned throughput and 25 GB of storage per month. It also documents reserved-capacity discounts for provisioned throughput and a flexible savings plan for eligible database workloads. Pricing was checked on August 25, 2026. Buyers should use the Azure pricing calculator and measure real RU consumption because query shape, indexing, item size, partitioning and region count can materially change the bill.

How should teams design partitioning?

Partitioning is central to Cosmos DB performance and scalability. Microsoft divides items into logical partitions based on a partition-key value, then maps those logical partitions across physical partitions as storage and throughput grow. A good partition key spreads both data and request load across many values so the service can scale horizontally without creating one overloaded hot partition.

A poor partition key can create uneven traffic, expensive cross-partition queries and scaling problems that are difficult to fix after large amounts of data are loaded. Teams should model their highest-volume reads and writes before choosing the key, estimate cardinality and growth, and understand that transactions in stored procedures or triggers are scoped to a single logical partition. Partition design deserves the same level of attention as schema design in a relational database.

Which consistency level should you choose?

Azure Cosmos DB offers five documented consistency levels: Strong, Bounded Staleness, Session, Consistent Prefix and Eventual. Strong gives the strongest read guarantee but can increase write latency and reduce read throughput in some distributed configurations. Session is widely used because it provides read-your-writes behavior within a session while retaining performance and availability characteristics closer to eventual consistency.

The correct choice depends on business semantics. Financial or state-machine workflows may require stronger guarantees, while feeds, telemetry and other distributed experiences may tolerate weaker consistency for lower latency or higher availability. Microsoft allows the account default to be changed and also supports request-level overrides in supported SDK scenarios, but teams should test application behavior carefully because consistency changes affect both correctness and performance.

How does global distribution and availability work?

Provisioned-throughput Cosmos DB accounts can replicate data across multiple Azure regions. Microsoft documents automatic routing and failover capabilities, and multi-region write configurations allow applications to write in more than one selected region. Microsoft currently advertises up to 99.999 percent read-and-write availability for qualifying multi-region configurations.

Global distribution is not free resilience. Additional regions increase throughput, storage and network costs, and consistency settings affect latency and failover behavior. Teams should decide where writes occur, how the application discovers endpoints, which regions are required for data residency, and how the system behaves during a regional outage. A globally distributed database should be tested with real failover scenarios rather than treated as automatically disaster-proof.

What are the main limitations and tradeoffs?

Cosmos DB can be expensive when applications use inefficient queries, oversized indexes, poor partition keys or too many replicated regions. Request-unit pricing rewards predictable access patterns, but teams unfamiliar with RU consumption can underestimate cost. Serverless is simpler for intermittent workloads but does not provide the same geo-distribution model as provisioned throughput.

The service also does not remove data-model responsibility. Developers still need to choose partition keys, indexes, consistency, API model, retention and security correctly. Applications migrated from relational databases may require significant redesign if they depend heavily on joins, multi-table transactions or stored procedures spanning many entities. Compatibility layers for MongoDB, Cassandra, Gremlin or Table should be validated against the exact features the application uses rather than assumed to be identical to the original database.

Who should choose something else?

Teams that need SQL Server compatibility, relational joins, mature T-SQL tooling or traditional relational transactions should compare Azure SQL Database. Applications with simple object-storage needs may be better served by Azure Blob Storage, while workloads that only need a cache or messaging layer should use the relevant Azure service instead of forcing the requirement into a database.

Azure Cosmos DB is strongest when the application genuinely benefits from horizontal partitioning, globally distributed access, predictable low latency and flexible NoSQL data models. Buyers should choose it because those distributed database capabilities solve a real workload requirement, not simply because it is a flagship Azure service.