Question 1

What is Azure Cosmos DB and where does it fit?

Accepted Answer

Azure Cosmos DB is Microsoft's managed multi-model NoSQL database with five APIs (SQL, MongoDB, Cassandra, Gremlin, Table), five tunable consistency levels, multi-master multi-region active-active, and integrated vector search. It fits when: (a) you're Azure-native with deep Cosmos DB integration (Azure Functions, Logic Apps, Synapse Link), (b) workload benefits from tunable per-query consistency (rare but powerful when needed), (c) multi-API consolidation matters (migrating Cassandra + MongoDB workloads to one platform), (d) integrated vector search for RAG fits the architecture.

Question 2

RU/s — what does it really mean and how to size it?

Accepted Answer

Request Unit per second (RU/s) is Cosmos DB's unified currency for read, write, and query cost. A 1KB read = 1 RU; a 1KB write = 5 RU; queries cost varies by complexity. You provision RU/s per container (or autoscale 10-100% range) and pay for what you provision. Sizing is harder than DynamoDB's RCU/WCU because query cost is unpredictable. Best practice: deploy with autoscale, monitor actual RU consumption via Azure Monitor, then refine to manual or tighter autoscale range based on observed patterns.

Question 3

Five consistency levels — when does tunable consistency matter?

Accepted Answer

Strong (linearizable reads), Bounded Staleness (reads lag by N versions or T duration), Session (read your writes within session — default), Consistent Prefix (no out-of-order reads), Eventual (best latency, eventual ordering). The reality: most workloads use Session and don't need to tune. Tunable matters for: cross-region read patterns where you want Bounded Staleness instead of Eventual, mixed workloads where some queries need Strong + others can tolerate Eventual, financial/inventory workloads explicitly requiring Strong. We model per-query needs before recommending non-default tuning.

Question 4

Multi-API — is the MongoDB API really compatible?

Accepted Answer

Cosmos DB's MongoDB API is wire-protocol compatible up to MongoDB 4.x semantics. Most MongoDB driver code works unchanged. Gaps: aggregation pipeline operators (some not supported), change streams (different semantics), full-text search (limited), some advanced operators. Cosmos for MongoDB vCore (separate offering, 2023+) is closer to native MongoDB — actual MongoDB-compatible engine on Azure. For greenfield MongoDB workloads on Azure, vCore is the better choice; for migrating existing MongoDB code with minimal changes, classic Cosmos MongoDB API works for ~85% of patterns.

Question 5

Multi-master vs single-master multi-region?

Accepted Answer

Single-master multi-region: one write region + N read regions, eventual consistency replication, automatic failover on region failure. Multi-master: all regions accept writes, last-writer-wins conflict resolution (configurable), better write latency for global users but more complex semantics. Multi-master earns its complexity for genuinely global write workloads (user-generated content, IoT telemetry from multiple regions, distributed gaming). For most workloads, single-master multi-region is simpler + sufficient. We model the workload before recommending.

Question 6

Integrated vector search — production-ready?

Accepted Answer

Cosmos DB added native vector search in 2024 across NoSQL API and MongoDB vCore. HNSW and flat indexes supported, integrated with Azure OpenAI / Azure AI Search for end-to-end RAG. For Azure-resident RAG workloads where you want documents + vectors in one engine, Cosmos vector search is competitive with MongoDB Atlas Vector Search. Limitations: smaller ecosystem of vector-tuning patterns vs Atlas, newer feature with less production track record. We benchmark on your data before recommending.

Question 7

Cosmos DB vs DynamoDB — when to pick which?

Accepted Answer

Cosmos DB wins when: you're Azure-native, multi-API consolidation matters, tunable consistency is a real requirement, integrated vector search fits the architecture. DynamoDB wins when: AWS-native with deep Lambda/Streams integration, workload is genuinely key-value with single-API needs, RCU/WCU per-second cost predictability matters more than RU/s flexibility. See /compare/dynamodb-vs-cosmosdb for the comparison.

Azure Cosmos DB, five APIs, globally distributed.

Cosmos DB service paths

Cosmos DB Consulting

DynamoDB vs Cosmos DB

What we build with Cosmos DB

RU/s sized right, consistency tuned

Queries we've transformed

Always on. Globally distributed.

A RU-throttling P1, handled in under 15 minutes.

Move to Cosmos DB without the downtime

Cosmos DB — common questions

Ready to optimise Cosmos DB?

Explore Our Cosmos DB Services

Compare Cosmos DB