Azure Cosmos DB: Globally Distributed NoSQL Database

Q: Cosmos DB or DynamoDB?

Both are managed, globally-capable NoSQL databases. Cosmos DB offers more data models (document, key-value, graph, wide-column), turnkey multi-region writes, five consistency levels, and MongoDB/Cassandra API compatibility. DynamoDB is AWS's equivalent (key-value/document, Global Tables). Choose by cloud primarily — Cosmos DB on Azure, DynamoDB on AWS — and by whether you need Cosmos's extra models and granular consistency.

Q: How is throughput priced?

In Request Units (RUs) — a normalized measure of the cost of database operations (a read costs some RUs, a query more, based on complexity). You either provision RUs (fixed or autoscale) or use serverless (pay per operation). Under-provisioning causes throttling; over-provisioning wastes money. Modeling your workload's RU consumption and choosing provisioned-autoscale vs serverless is the key cost decision.

Q: Can I migrate my MongoDB app to Cosmos DB?

Yes — Cosmos DB offers a MongoDB-compatible API (wire protocol), so many MongoDB applications can point at Cosmos DB with minimal changes, gaining Azure integration and global distribution. (There's also a Cassandra-compatible API.) These compatibility APIs are aimed at migration; for new apps, the native NoSQL API is generally the better choice.

Azure Cosmos DB

Azure Cosmos DB is Microsoft Azure's globally distributed, multi-model NoSQL database — built for applications that need low-latency access to data from anywhere in the world, elastic scale, and high availability. Its signature capability is turnkey global distribution: you can replicate your data across any number of Azure regions with a click, and reads/writes are served from the region nearest each user, with single-digit-millisecond latency backed by SLAs. It's Azure's flagship NoSQL offering and its answer to AWS DynamoDB (with more models and global-write flexibility).

Cosmos DB is "multi-model," exposing several APIs so you can use it as a document store, key-value store, graph database, or wide-column store — and, notably, with API compatibility for MongoDB and Cassandra so existing apps can migrate. Its distinctive feature beyond global distribution is five tunable consistency levels, letting you trade consistency for latency/availability precisely rather than the usual all-or-nothing choice. The NoSQL and database concepts apply; this is the managed, globally-distributed Azure service.

TL;DR

Cosmos DB is a globally distributed, multi-model NoSQL database — turnkey replication across Azure regions with low-latency, SLA-backed reads/writes near each user.
Multi-model via APIs: NoSQL (native document/SQL-like queries), MongoDB, Cassandra, Gremlin (graph), Table — pick the API/model that fits (or migrate existing MongoDB/Cassandra apps).
Turnkey global distribution — add regions with a click; optional multi-region writes (write anywhere, not just one primary).
Five consistency levels (Strong → Bounded Staleness → Session → Consistent Prefix → Eventual) — tune the consistency/latency trade-off precisely.
Scales via partitioning (choose a good partition key — critical) and is billed in Request Units (RUs) (provisioned or serverless/autoscale).
vs DynamoDB: Cosmos offers more data models, multi-region writes, and granular consistency; DynamoDB is AWS's equivalent. Choose by cloud and model needs.

Core Concepts

Global Distribution

Cosmos DB's headline feature: replicate data across Azure regions with a click, and it serves each user from the nearest region for low latency. Two modes:

Single-region writes — one region accepts writes, others serve reads (like most globally-replicated databases).
Multi-region writes (multi-master) — any region accepts writes, with automatic conflict resolution. This lets a globally-distributed app write locally everywhere, eliminating cross-region write latency — a capability few databases offer turnkey.

Combined with SLA-backed single-digit-millisecond latency and 99.999% availability (multi-region), this makes Cosmos DB a strong fit for globally-distributed, latency-sensitive applications.

Multi-Model APIs

Cosmos DB exposes multiple APIs so one service covers several data models:

The NoSQL (Core) API is the native, most fully-featured choice for new apps; the MongoDB/Cassandra APIs exist mainly for migrating existing applications without rewriting them. Pick the model that fits your data and access patterns.

Consistency Levels

Most distributed databases force a binary choice (strong vs eventual consistency); Cosmos DB offers five levels, letting you tune precisely:

Strong — linearizable; reads always see the latest write (highest latency, single-region-write only in practice).
Session (default) — read-your-own-writes within a session; a good balance for most apps.
Eventual — lowest latency, highest availability; reads may lag.

This granularity lets you match consistency to each workload's needs rather than accepting one global trade-off — a genuinely distinctive feature.

Partitioning and Request Units

Partitioning — Cosmos DB scales horizontally by distributing data across partitions based on a partition key you choose. This choice is critical: a good key spreads data and load evenly; a bad one creates "hot partitions" (one partition getting disproportionate traffic) that throttle and limit scale. Choosing the partition key well is the single most important Cosmos DB design decision.
Request Units (RUs) — throughput is measured and billed in RUs (a normalized cost of operations). You provision RUs (manual or autoscale) or use serverless (pay per operation) for spiky/dev workloads. Under-provisioning causes throttling; over-provisioning wastes money — RU management is the core cost discipline.

Cosmos DB vs DynamoDB vs MongoDB

Cosmos DB's differentiators: multiple data models in one service, turnkey multi-region writes, and five granular consistency levels. DynamoDB is AWS's comparable managed NoSQL (key-value/document, Global Tables for multi-region). MongoDB Atlas is the cloud-agnostic document database (and Cosmos offers a MongoDB-compatible API). Choose by cloud, data model, and global-distribution needs — for Azure apps needing global scale and flexible consistency, Cosmos DB is the flagship option.

Common Mistakes

Poor Partition Key Choice

The #1 Cosmos DB mistake. A partition key that concentrates data or traffic ("hot partitions") — e.g. keying by a low-cardinality field, or one that funnels writes to a single partition — throttles performance and caps scalability. Choose a key with high cardinality that distributes load evenly across access patterns. This decision is hard to change later; get it right upfront.

Over- or Under-Provisioning RUs

Provisioning too few Request Units causes throttling (429 errors) under load; too many wastes money. Use autoscale (scales RUs with demand within a range) or serverless (pay-per-operation) for variable/spiky workloads, and monitor RU consumption. RU management is the core cost and performance lever. See cloud costs.

Using the MongoDB/Cassandra API for New Apps

The compatibility APIs exist to migrate existing MongoDB/Cassandra apps. For new applications, the native NoSQL (Core) API has the richest features and best integration. Choosing a compatibility API for a greenfield app forgoes native capabilities for compatibility you don't need.

Defaulting to Strong Consistency Everywhere

Strong consistency has the highest latency and limits global write flexibility. Most apps work well with Session (the default — read-your-writes) or weaker levels, gaining lower latency and higher availability. Reserve Strong for the specific data that genuinely needs linearizability; tuning per-workload is the point of five levels.

Treating It Like a Relational Database

Cosmos DB is NoSQL — model for your access patterns (denormalize, embed), not normalized tables with joins. Trying to use it relationally (many small documents needing joins, complex cross-partition queries) fights the model and hits performance/cost issues. Model around how you query, as with any NoSQL database.

FAQ

What makes Cosmos DB "globally distributed"?

You can replicate its data across any Azure regions with a click, and it automatically serves each user from the nearest region with SLA-backed low latency (single-digit milliseconds). With multi-region writes enabled, any region can accept writes (not just one primary), so a global app writes locally everywhere. This turnkey global distribution — few databases offer it so easily — is Cosmos DB's signature capability.

What are the five consistency levels for?

They let you tune the consistency vs latency/availability trade-off precisely: Strong (always latest, highest latency) → Bounded Staleness → Session (default, read-your-writes) → Consistent Prefix → Eventual (lowest latency, may lag). Instead of the usual binary strong-vs-eventual choice, you pick the exact balance each workload needs. Most apps use Session; you tighten or loosen from there.

Cosmos DB or DynamoDB?

Both are managed, globally-capable NoSQL databases. Cosmos DB offers more data models (document, key-value, graph, wide-column), turnkey multi-region writes, five consistency levels, and MongoDB/Cassandra API compatibility. DynamoDB is AWS's equivalent (key-value/document, Global Tables). Choose by cloud primarily — Cosmos DB on Azure, DynamoDB on AWS — and by whether you need Cosmos's extra models and granular consistency.

How is throughput priced?

In Request Units (RUs) — a normalized measure of the cost of database operations (a read costs some RUs, a query more, based on complexity). You either provision RUs (fixed or autoscale) or use serverless (pay per operation). Under-provisioning causes throttling; over-provisioning wastes money. Modeling your workload's RU consumption and choosing provisioned-autoscale vs serverless is the key cost decision.

Can I migrate my MongoDB app to Cosmos DB?

Yes — Cosmos DB offers a MongoDB-compatible API (wire protocol), so many MongoDB applications can point at Cosmos DB with minimal changes, gaining Azure integration and global distribution. (There's also a Cassandra-compatible API.) These compatibility APIs are aimed at migration; for new apps, the native NoSQL API is generally the better choice.