Cosmos DB

What is Azure Cosmos DB?

Azure Cosmos DB is Microsoft’s globally-distributed, multi-model database service. Its headline capabilities are turnkey global distribution (replicate your data across any number of Azure regions with a few clicks, for low-latency reads worldwide and regional failover) and multiple APIs (it can present as a document store via the MongoDB or its native NoSQL API, a key-value/wide-column store via Cassandra, a graph store via Gremlin, or a table store) so you can use familiar programming models on one backend. It’s Azure’s answer to globally-scaled applications, and it competes with AWS DynamoDB in the managed, planet-scale NoSQL space.

The genuinely distinctive feature: five consistency levels

Most distributed databases give you a binary choice — strong consistency or eventual consistency. Cosmos DB’s most interesting design decision is offering five tunable consistency levels along the spectrum: strong (always read the latest write, at the cost of latency and availability), bounded staleness (reads lag writes by at most a set amount of time or number of versions), session (consistency within a single client session — the sensible default for many apps, so you read your own writes), consistent prefix (reads never see out-of-order writes), and eventual (fastest and cheapest, may read stale). This directly exposes the CAP/PACELC tradeoffs as a configuration choice rather than an architectural fait accompli — you dial in exactly how much consistency you’re willing to pay latency and cost for. It’s a genuinely useful model, and understanding it is the key to using Cosmos DB well: most workloads don’t need strong consistency everywhere, and defaulting to it (or to eventual, blindly) both cost you and surprise you.

The cost model will bite you if you model badly

Cosmos DB’s pricing is built on Request Units (RUs) — a normalized currency for throughput where every operation (read, write, query) consumes some RUs, and you either provision RU/s capacity or pay per-request (serverless/autoscale). This is the single most important thing to understand, because RU consumption is dominated by your data model and query patterns, and bad modeling gets expensive fast. The specific traps: choosing a poor partition key creates “hot partitions” that throttle (the same failure mode as DynamoDB) while wasting provisioned throughput elsewhere; cross-partition queries and queries without the partition key fan out and burn far more RUs; unindexed or over-indexed containers cost more (Cosmos indexes everything by default, which aids queries but raises write RU cost — tuning the indexing policy matters); and turning on strong consistency or many-region writes multiplies cost. Teams routinely get a shocking bill because they modeled Cosmos like a relational database — normalized, join-heavy, partition-key-agnostic — and every query fans across partitions at premium RU rates. Used well (access-pattern-driven modeling, a partition key that spreads load evenly, the right consistency level per workload) it’s powerful; used carelessly it’s a fast way to overspend.

What people get wrong

• A poor partition key — it causes hot partitions that throttle and cross-partition queries that burn RUs; the key choice dominates both performance and cost.
• Defaulting consistency thoughtlessly: strong everywhere is expensive and slow; eventual everywhere surprises users — pick the level per workload (session is often right).
• Relational modeling — normalized, join-heavy designs fan out across partitions at premium RU rates; model around access patterns like any NoSQL store.

Primary source: Azure Cosmos DB documentation