Azure Cosmos DB vs Amazon DynamoDB
Azure Cosmos DB vs Amazon DynamoDB compared: data models and APIs, consistency levels, pricing (RU/s vs capacity units), global distribution, indexing and queries, limits, vector search and when to choose each.
Quick Answer
Amazon DynamoDB is a key-value and document database with single-digit-millisecond performance, serverless on-demand pricing and a design that rewards modelling around access patterns. Azure Cosmos DB is a multi-model, globally distributed database with five consistency levels, automatic indexing, a SQL-like query language and compatibility APIs for MongoDB, Cassandra, Gremlin and Table. Usually the choice follows your cloud: DynamoDB on AWS, Cosmos DB on Azure.
Reviewed by TechLogHub Engineering Team. Last updated November 7, 2026. New comparison written for November 2026, reflecting current capacity modes, global table options and vector search support in both services.
| Feature | Azure Cosmos DB | Amazon DynamoDB |
|---|---|---|
| Cloud provider | Microsoft Azure | Amazon Web Services |
| Data model and APIs | Document (NoSQL API), plus MongoDB, Cassandra, Gremlin and Table APIs | Key-value and document |
| Query language | SQL-like query language (NoSQL API) | Key-based API, PartiQL (SQL-compatible) |
| Indexing | Automatic on all properties; customisable policy | Primary key plus global and local secondary indexes you define |
| Consistency options | Strong, bounded staleness, session, consistent prefix, eventual | Eventually or strongly consistent reads; multi-region strong consistency option for global tables |
| Global distribution | Multi-region replication, optional multi-region writes | Global tables (multi-active) |
| Capacity and pricing model | Request Units: provisioned (manual or autoscale) or serverless | On-demand (per request) or provisioned capacity units |
| Maximum item size | 2 MB | 400 KB |
| Transactions | ACID within a logical partition (stored procedures, transactional batch) | ACID across up to 100 items and multiple tables |
| Change streams | Change feed | DynamoDB Streams, Kinesis Data Streams |
| Vector search | Built-in vector indexing (NoSQL API) | Via zero-ETL integration with OpenSearch Service |
| Free tier | Free tier: 1,000 RU/s and 25 GB per eligible account | Always-free tier: 25 GB storage and 25 provisioned read and write capacity units |
| Availability SLA | Up to 99.999% with multi-region | 99.99% (99.999% for global tables) |
Azure Cosmos DB
Microsoft Azure's fully managed, globally distributed NoSQL database. It offers a native NoSQL (document) API with SQL-like queries plus APIs compatible with MongoDB, Apache Cassandra, Gremlin and Azure Table storage.
Pros
- Five well-defined consistency levels, from strong to eventual, with session consistency as the default
- Automatic indexing of every property by default, so ad hoc queries work without designing indexes up front
- Turnkey multi-region distribution with optional multi-region writes
- SQL-like query language with filters, projections, aggregates and joins within a document
- Multiple APIs let teams bring MongoDB or Cassandra workloads with fewer code changes
- Integrated vector search in the NoSQL API using DiskANN-based indexes, plus full-text and hybrid search
Cons
- Request Unit (RU) pricing takes time to understand and estimate
- Cross-partition queries can be expensive in RUs if the partition key is poorly chosen
- Automatic indexing increases write cost unless you tune the indexing policy
- Features and limits differ between APIs, which complicates comparisons
Best For
Azure-based applications, globally distributed apps that need tunable consistency, workloads with ad hoc query needs, and migrations of MongoDB or Cassandra apps onto Azure.
Amazon DynamoDB
AWS's fully managed, serverless key-value and document database. It delivers consistent single-digit-millisecond latency at virtually any scale and is designed around partition and sort keys plus secondary indexes.
Pros
- Truly serverless: no servers, versions or maintenance windows to manage
- On-demand mode scales instantly and bills per request; provisioned mode with auto scaling for steady loads
- Predictable low latency at very large scale with careful key design
- Deep AWS integration: Lambda triggers via Streams, IAM, zero-ETL integrations, S3 export and import
- Global tables provide multi-active, multi-region replication
- ACID transactions across multiple items and tables
Cons
- Access-pattern-first modelling (often single-table design) has a steep learning curve
- Limited query flexibility: queries must use keys or secondary indexes; scans are costly
- 400 KB maximum item size
- No native vector search; similarity search needs the OpenSearch integration or another store
- Available only on AWS
Best For
AWS-based applications, serverless architectures with Lambda, high-scale key-value workloads such as sessions, carts, gaming and IoT, and teams that know their access patterns up front.
Data modelling and queries
DynamoDB tables have a partition key and an optional sort key, and every efficient read uses them: GetItem by key, Query within a partition with sort key conditions, or the same through a global or local secondary index. Scans read the whole table and are slow and expensive, so experienced teams list their access patterns first and design keys around them, often putting several entity types in one table (single-table design). PartiQL offers SQL-like syntax but follows the same key rules. Cosmos DB's NoSQL API stores JSON documents in containers with a partition key, indexes every property automatically, and supports a SQL-like language with WHERE filters, ORDER BY, aggregates and joins within a document's arrays. That makes ad hoc and evolving queries easier, although queries that span many partitions consume more Request Units. In both services, the partition key is the most important design decision: a high-cardinality key that spreads traffic evenly avoids hot partitions and throttling.
Consistency and global distribution
Cosmos DB is known for offering five consistency levels, each with a precise definition: strong, bounded staleness, session (the default, giving read-your-own-writes within a session), consistent prefix and eventual. You set a default per account and can relax it per request, trading latency and cost against freshness. Accounts can replicate to any number of Azure regions, optionally accepting writes in every region with configurable conflict resolution. DynamoDB offers eventually consistent reads by default and strongly consistent reads within a region at twice the read cost. Global tables replicate a table across AWS regions with multi-active writes and last-writer-wins conflict resolution, and AWS has added a multi-region strong consistency option for global tables, for applications that need a zero recovery point objective. Both offer five-nines availability SLAs for multi-region configurations, so the practical difference is how much control you want over consistency semantics.
Pricing models: Request Units vs capacity units
Cosmos DB charges for throughput in Request Units, an abstract unit covering CPU, memory and I/O, where a 1 KB point read costs about one RU and writes and queries cost more. You can provision RU/s manually, use autoscale, which scales between 10 percent and 100 percent of a maximum and bills for the highest level used each hour, or choose serverless and pay per RU consumed, which suits development and spiky low-traffic apps. Storage is billed separately. DynamoDB offers on-demand mode, billed per read and write request, and provisioned mode with read and write capacity units plus optional auto scaling and reserved capacity for steady workloads; storage, backups, streams and global table replication are billed separately. AWS cut on-demand prices significantly in late 2024, which made on-demand the sensible default for many tables. In both services, item size, index count and query patterns drive cost more than the headline rates, so measure with real traffic.
Ecosystem, vector search and migrations
DynamoDB's strength is integration with AWS: Streams trigger Lambda functions for event-driven designs, IAM policies control access down to items and attributes, DAX adds an in-memory cache, and zero-ETL integrations replicate data to OpenSearch Service and Redshift for search and analytics without custom pipelines. Point-in-time recovery and exports to S3 cover backup and analytics. Cosmos DB integrates with Azure Functions through its change feed, Microsoft Entra ID for access control, Synapse Link and Microsoft Fabric for analytics, and offers native vector indexing and full-text search in its NoSQL API, which makes it a candidate for retrieval-augmented generation apps that want operational data and embeddings in one store. For migrations, Cosmos DB's MongoDB and Cassandra compatible APIs can reduce application changes, while moving to DynamoDB from another database usually means remodelling data around access patterns.
Verdict
For most teams the decision between Cosmos DB and DynamoDB follows the cloud they already use, because each integrates deeply with its own platform's identity, networking, serverless functions and monitoring, and neither runs on the other's cloud. If you are on AWS, DynamoDB is the default NoSQL choice: serverless, extremely scalable and predictable, with on-demand pricing that suits spiky workloads and tight Lambda integration. Its trade-off is modelling effort, since you design tables and indexes around known access patterns and ad hoc queries are limited. If you are on Azure, Cosmos DB is the natural choice and offers more flexibility: automatic indexing, a SQL-like query language, five consistency levels, multi-region writes, built-in vector search and compatibility APIs for MongoDB and Cassandra. Its trade-off is cost modelling with Request Units and the importance of choosing a good partition key. If you are cloud-neutral, choose DynamoDB for simple, high-volume key-value access with minimal operations, and Cosmos DB for globally distributed apps that need tunable consistency, richer queries or vector search in the same database. Prototype with real access patterns and estimate costs with each provider's calculator before committing.