Sound familiar?
- ▸ RCU/WCU provisioning math doesn't match the real load shape — on-demand is doubling spend but provisioned mode is throwing 400s during peak, and the partition-key design is suspect.
- ▸ RU/s estimation for a new Cosmos workload is wrong by 5x and the autoscale tier hasn't saved enough — finance wants a rebid before the next quarter, and the team needs a real capacity model.
- ▸ Multi-region requirements just landed — regulator wants in-region writes, app team wants active-active. Global Tables vs Cosmos multi-master is the architecture call that hasn't been made.
JusDB consultants build the written DynamoDB-vs-Cosmos DB decision with a partition-key audit attached. Book a cloud-NoSQL scoping call →
DynamoDB vs Cosmos DB
RCU/WCU vs RU/s. Global Tables vs multi-master. Single-API vs five-API surface. Vector search, consistency models, partition-key design — the cloud-native NoSQL decision in 2026.
Feature matrix
| Dimension | Amazon DynamoDB | Azure Cosmos DB |
|---|---|---|
| Cloud | AWS only | Azure only |
| API surface | DynamoDB native (PutItem / GetItem / Query / Scan) | SQL (native), MongoDB, Cassandra, Gremlin, Table |
| Pricing model | RCU/WCU + storage + transfer; provisioned or on-demand | RU/s (unified) + storage; provisioned, autoscale, or serverless |
| Consistency model | Strong or eventual (per read); last-writer-wins across regions | Five tunable levels: strong / bounded staleness / session / consistent prefix / eventual |
| Multi-region | Global Tables — active-active, eventual cross-region | Multi-master — active-active with per-workload consistency choice |
| Indexing | Global Secondary Index, Local Secondary Index — pre-declared | Automatic on all properties + composite indexes + spatial |
| Transactions | TransactWriteItems / TransactGetItems — up to 100 items, single region | Stored-procedure transactions within partition; cross-doc with batch |
| Vector search | Via Amazon OpenSearch Service or Bedrock Knowledge Bases (external) | Native — HNSW + flat indexes inside SQL API and MongoDB vCore |
| Change feeds | DynamoDB Streams (24h retention) + Kinesis Data Streams integration | Change feed (built-in, persistent), Azure Event Hubs integration |
| Backup | PITR (35-day window) + on-demand snapshots | Continuous (30 days) or periodic backups, GA in all tiers |
| Free tier | 25 GB storage + 25 RCU/25 WCU permanent free tier | 1000 RU/s + 25 GB free, 30 days; serverless beyond that |
When DynamoDB wins
- You're on AWS and the rest of the stack is AWS-native.
- Steady, predictable read/write throughput — provisioned capacity is cheaper.
- Access pattern is genuinely key-value — no need for multi-API flexibility.
- You want the deepest AWS integration: Lambda triggers, Streams, IAM, KMS, VPC.
- PITR + Global Tables cover your DR and multi-region needs.
- You're happy with eventual consistency cross-region (last-writer-wins).
When Cosmos DB wins
- You're on Azure and the rest of the stack is Azure-native.
- Tunable consistency per workload is a real architectural requirement.
- You want MongoDB / Cassandra / Gremlin API to migrate without rewriting.
- Vector search co-located with primary documents simplifies RAG architecture.
- Multi-master with strong cross-region consistency is required.
- Automatic indexing on all properties is operationally easier than DynamoDB's GSI/LSI design.
Migration
Migration paths between DynamoDB and Cosmos DB
DynamoDB → Cosmos DB
Pick the Cosmos API first — usually the native SQL API for a fresh design or Table API for the closest DynamoDB ergonomic match. Re-shape the data model, write the migration script (DynamoDB scan → Cosmos batch insert), and validate the new partition key.
Cosmos DB → DynamoDB
Trickier when you're moving off Cosmos MongoDB API — re-targeting at DynamoDB native requires rewriting all queries since DynamoDB has no $match / $group / $lookup. Often the easier path is Cosmos → MongoDB Atlas instead.
Either → MongoDB Atlas (multi-cloud)
Common destination when teams want out of single-cloud lock-in. Atlas runs on AWS, Azure, and GCP equally well, with replica sets and sharding native. We help model the migration plus the operational handoff.
Common questions
Need a written DynamoDB-vs-Cosmos decision?
We audit the partition-key design, model the throughput, and write the migration runbook — for either direction or for the "move off cloud-native" option.