Azure Cosmos DB
Globally distributed, multi-model NoSQL database with single-digit-millisecond latency at the 99th percentile and five well-defined consistency levels.
Why
Cosmos DB is the only Azure database offering turnkey multi-master replication with SLA-backed latency, throughput, consistency, and availability. It speaks SQL, MongoDB, Cassandra, Gremlin, and Table APIs, so you can migrate existing apps without changing drivers. Azure holds 21% cloud market share (Synergy Research Q4 2024).
Azure is the default for enterprises with Microsoft 365 / Active Directory estates — 95% of Fortune 500 use Azure. AKS and Cosmos DB are first-class for .NET workloads.
When
Use Cosmos DB for globally distributed apps needing low-latency reads/writes everywhere, IoT telemetry at high write volume, or when you need MongoDB/Cassandra API compatibility without managing clusters. Avoid it for heavy analytics — use Synapse Link or BigQuery instead, as RU cost of full-table scans is prohibitive.
How
Example
Common Problems
- ⚠RequestRateTooLarge (429) errors — RU/s is too low for the workload; enable autoscale or increase throughput, and batch/bulk-insert to amortize RU cost.
- ⚠Hot partition — all writes hit one partition key value (e.g., a timestamp bucket); choose a high-cardinality partition key that spreads writes evenly.
- ⚠Cross-partition query is slow and expensive — your query does not include the partition key; always filter on the partition key to keep queries single-partition.
Best Practices
- ✓Choose a partition key with high cardinality and even write distribution; the partition key determines how data is sharded and is immutable after creation.
- ✓Use autoscale throughput for variable workloads — it scales RU/s automatically between 10% and 100% of the max, avoiding 429s without overpaying.
- ✓Enable Synapse Link (analytical store) to run analytical queries on a column-store replica without consuming transactional RUs.
FAQ
What is Azure Cosmos DB and what problem does it solve?
Globally distributed, multi-model NoSQL database with single-digit-millisecond latency at the 99th percentile and five well-defined consistency levels. It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.
How do I get started with Azure Cosmos DB in 5 minutes?
Two steps to run it: (1) Create a Cosmos account and pick an API (SQL/Mongo/Cassandra/Gremlin/Table).; (2) Create a database and one or more containers, each with a partition key.. Validate on the free tier first, then wire into production.
What is the #1 pitfall with Azure Cosmos DB?
The most frequent issue is: RequestRateTooLarge (429) errors — RU/s is too low for the workload; enable autoscale or increase throughput, and batch/bulk-insert to amortize RU cost.. Run a pre-launch checklist item by item, and add policy/config scanning in CI.
What are the best practices for Azure Cosmos DB?
Best practices for Azure Cosmos DB include: Choose a partition key with high cardinality and even write distribution; the partition key determines how data is sharded and is immutable after creation.; Use autoscale throughput for variable workloads — it scales RU/s automatically between 10% and 100% of the max, avoiding 429s without overpaying.; Enable Synapse Link (analytical store) to run analytical queries on a column-store replica without consuming transactional RUs.. The first one — "Choose a partition key with high cardinality and even write distribution; the partition key determines how data is sharded and is immutable after creation." — should be a team default baked into your IaC templates.
How do I control cost and avoid bill surprises with Azure Cosmos DB?
Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most Azure Cosmos DB options offer a free tier — validate within free quota before scaling.