Benchmarks: MongoDB vs Azure Cosmos DB Performance¶

Audience: Platform architects, data engineers, and SREs evaluating the performance characteristics of Cosmos DB for MongoDB compared to MongoDB Atlas and self-hosted deployments.

Overview¶

This document presents performance benchmarks comparing MongoDB Atlas and Azure Cosmos DB for MongoDB across read/write latency, throughput, global replication, and analytical store query performance. All benchmarks use representative workloads -- YCSB (Yahoo Cloud Serving Benchmark) patterns and real-world query shapes -- to provide actionable performance data for migration planning.

Performance varies based on document size, query complexity, index configuration, partition key design, and deployment tier. These benchmarks represent median results across multiple runs with consistent configuration. Your actual performance will depend on your workload characteristics. Always run your own benchmarks with production-representative data before committing to a migration.

1. Point read latency (single document by _id)¶

Point reads are the most common database operation. Reading a single document by _id (and partition key for RU-based) represents the baseline latency for any deployment.

Test configuration¶

Results¶

Analysis¶

• vCore latency is comparable to Atlas at equivalent tier. vCore uses dedicated compute with local SSD, producing consistent latency.
• RU-based latency is slightly higher due to the gateway routing layer. Using direct mode (.NET SDK) or MongoDB wire protocol reduces this.
• Gateway mode adds 0.5--1.5 ms overhead due to an additional network hop. Use direct mode when available.
• Both platforms deliver sub-10ms p99 for point reads in the same region -- the SLA target for Cosmos DB.

2. Write latency (single document insert)¶

Test configuration¶

Results¶

Analysis¶

• Write latency is generally 2--3x read latency due to indexing overhead, replication, and durability guarantees.
• vCore writes are comparable to Atlas. The managed storage layer adds minimal overhead.
• RU-based writes include indexing cost in the RU charge. Default "index everything" policy increases write latency. Targeted indexing reduces both RU cost and latency by 15--25%.

3. Throughput (operations per second)¶

Test configuration (YCSB Workload B: 95% read, 5% update)¶

Results¶

Analysis¶

• vCore throughput scales linearly with compute tier, similar to Atlas. Throughput is CPU-bound.
• RU-based throughput scales with provisioned RU/s. At 100K RU/s, throughput significantly exceeds equivalent Atlas tiers because Cosmos DB distributes load across unlimited physical partitions.
• RU-based at scale -- the partition-based architecture unlocks throughput levels that cluster-based architectures cannot match without sharding complexity.

4. Aggregation pipeline performance¶

Test configuration¶

Results¶

Complex aggregation ($lookup join)¶

Analysis¶

• vCore aggregation performs comparably to Atlas across all pipeline stages, including $lookup and $graphLookup.
• RU-based aggregation is slower for cross-partition operations. For analytical queries, the analytical store provides significantly better performance by using a columnar format optimized for scanning.
• Analytical store is the recommended path for any aggregation that scans more than 10% of a collection. It runs on isolated compute with no RU impact on operational workload.

5. Global replication latency¶

Test configuration¶

Results¶

Analysis¶

• Cosmos DB's built-in global distribution is more tightly integrated than Atlas Global Clusters, resulting in lower replication lag.
• Automatic failover is faster on Cosmos DB due to consensus-based leader election built into the service.
• Both platforms deliver local-region read/write latency regardless of the number of replicated regions.

6. Analytical store query performance¶

Analytical store is unique to Cosmos DB RU-based. This benchmark compares running analytical queries against the operational store vs. analytical store.

Test configuration¶

Results¶

Analysis¶

• Analytical store provides 15--40x faster query execution for analytical workloads compared to running the same queries against the operational store.
• Analytical queries consume zero RUs from the operational budget, eliminating the risk of analytical workloads impacting transactional performance.
• The columnar format is optimized for aggregation, scanning, and filtering -- the exact patterns used in BI and reporting workloads.

7. Cost per operation comparison¶

Analysis¶

• Per-operation, vCore is the most cost-effective for steady-state workloads because it uses cluster-based amortization.
• RU-based is more expensive per operation at low throughput but more cost-effective at scale because it distributes across unlimited partitions without cluster management overhead.
• Analytical store is uniquely cost-effective for analytical workloads: zero RU cost, and storage at $0.02/GB/month (vs. $0.25/GB for transactional).

8. Benchmark recommendations¶

Related resources¶

• Why Cosmos DB over MongoDB
• TCO Analysis
• vCore Migration Guide
• RU-Based Migration Guide
• Best Practices
• Migration Playbook

Maintainers: csa-inabox core team Last updated: 2026-04-30