DynamoDB vs Cosmos DB: Features, Scaling, and Cost

Azure Cosmos DB for NoSQL is the closest Azure counterpart to DynamoDB for managed, globally distributed document and key-value workloads. Choose DynamoDB for AWS integration and predictable key-based access; choose Cosmos DB when Azure integration, its query model, and its consistency choices fit your application. Neither is a drop-in replacement for a relational database, and their capacity units are not interchangeable.

An overview of DynamoDB and Cosmos DB

DynamoDB

DynamoDB stores items in tables with a partition key and an optional sort key. Non-key attributes can vary between items. AWS manages the storage and replication infrastructure, while you design access patterns, indexes, permissions, and recovery settings.

The service offers regional transactions, change streams, on-demand and provisioned capacity, and multi-Region global tables. It also supports native vector indexes on supported on-demand tables. These capabilities have individual limits; buying a managed service does not remove data-modeling decisions.

Cosmos DB

Cosmos DB organizes data into accounts, databases, containers, and items. Microsoft's resource model documents APIs for NoSQL, MongoDB, Apache Cassandra, Apache Gremlin, and Table. API choice affects the interface, data model, and supported features. Compatibility APIs do not mean the service runs the upstream database engine or implements every upstream feature.

This comparison focuses on Cosmos DB for NoSQL, the native document API formerly called the SQL API. It stores JSON documents and supports SQL-like queries. Graph traversal through Gremlin and Cassandra-compatible CQL are separate API choices, not extra query languages you can freely apply to the same NoSQL container.

Comparison at a glance

Item limits come from the DynamoDB constraints and Cosmos DB service limits. Cosmos DB limits can differ by API, so do not transfer the NoSQL limit to every MongoDB-compatible deployment.

Shared attributes and query differences

Both services provide managed partitioning, replication, encryption, and backup options. Both can hold flexible documents, and both need a partition strategy that distributes load while keeping important queries efficient.

DynamoDB Query selects a partition-key value and optionally a sort-key condition. Additional filters run after the read, so a selective-looking filter can still consume substantial capacity. Secondary indexes provide alternate access paths; they also add storage and write costs.

Cosmos DB for NoSQL provides SQL-like filtering and projection over documents, with an indexing policy that controls which paths are indexed. A query spanning many partitions can consume much more work than a point read. Automatic indexing is convenient, but the application should still inspect request charges and query diagnostics.

Neither service turns SQL syntax into a full relational model. If your application depends on general cross-table joins, changing relational queries, or broad transactional boundaries, evaluate that requirement before selecting either database. Denormalization can simplify reads, but duplicated data creates update responsibilities.

Performance

DynamoDB

Key-based operations are designed for low latency. The important inputs are item size, key distribution, index design, request concurrency, and retries. Avoid treating a service-wide throughput milestone as a performance promise for one table or one key.

DynamoDB Accelerator (DAX) caches compatible reads. It does not make every read and write a fixed multiple faster. Adaptive capacity helps distribute available throughput to busy partitions; it does not replace provisioned-capacity auto scaling or override every partition limit.

Cosmos DB

A point read using the document ID and partition key is a different operation from a cross-partition query. Measure their latency and RU consumption separately. Consistency, indexing, document size, and geographic placement all affect the result.

Cosmos DB availability and latency commitments depend on the chosen deployment and the applicable SLA terms. Multi-Region configuration is deliberate: creating an account does not automatically place application replicas in every Azure Region. Test SDK retries and failover as part of the design, rather than reporting an unconditional uptime percentage.

Vector search

Cosmos DB vector search stores embeddings alongside documents and offers flat, quantized-flat, and DiskANN index choices. Define the vector policy and index settings to fit the workload, then measure recall, latency, and RU cost.

DynamoDB also supports native vector indexes and a dedicated search API on supported on-demand tables. Evaluate supported dimensions, filtering, regional availability, and freshness for either service. An existing document or key index is not automatically a vector index.

Consistency and transactions

Cosmos DB documents five consistency levels: strong, bounded staleness, session, consistent prefix, and eventual. Session consistency supports guarantees within a client session; it should not be described as global strong consistency. Accounts with multiple write regions cannot use strong consistency.

DynamoDB supports optional strongly consistent reads on tables and local secondary indexes, while global secondary indexes are eventually consistent. Global tables offer MREC and MRSC modes. MRSC provides cross-Region strong reads, with feature restrictions including no transaction APIs or TTL.

Transaction scope is another major design difference. DynamoDB's transaction APIs can span items in tables within the same account and Region. Cosmos DB transactional batches group operations sharing a logical partition key in one container. Design an order and its dependent updates around the guarantees of the specific API you will call.

Security

DynamoDB integrates with IAM roles and policies, resource-based policies, and KMS. Encryption at rest is always on, and VPC endpoints offer private network paths. Prefer scoped workload identities to credentials embedded in application code.

Cosmos DB for NoSQL supports Microsoft Entra ID, role-based access, and private networking. “Azure Active Directory” is the older name for Microsoft Entra ID. Account keys remain an access mechanism, but shared keys are not the only authentication option.

Both products separate network access from authorization. A private endpoint does not grant a principal access to records, and an application identity does not by itself disable public network access. Configure both layers and verify backup access as well.

Scalability and capacity modes

DynamoDB offers on-demand request billing or provisioned read/write capacity. Provisioned capacity can be adjusted manually or with auto scaling. On-demand tables can have optional maximum-throughput settings, and warm throughput indicates the traffic they can absorb immediately. Neither mode eliminates hot keys.

Cosmos DB offers three distinct capacity choices:

1. Manual provisioned throughput: reserve RU/s for a database or container and pay for that capacity even when idle.
2. Autoscale provisioned throughput: set a maximum and let throughput vary within the documented range. It is still provisioned capacity, not per-request serverless billing.
3. Serverless: pay for consumed RUs and storage without provisioning RU/s. It suits intermittent workloads when its restrictions fit.

For autoscale, the range is 0.1 * Tmax <= T <= Tmax. A maximum of 20,000 RU/s gives a range of 2,000 to 20,000 RU/s. Dynamic scaling can adjust individual regions and partitions independently for uneven workloads. Check billing and storage-driven minimums before treating the configured maximum as the only relevant number.

Cosmos DB serverless runs in one Azure Region. It is not the same global deployment option as provisioned throughput, and it is not automatically the cheapest choice for sustained traffic. Compare measured demand against the capacity models rather than choosing by their names.

Backups

DynamoDB offers on-demand backups and restores and configurable point-in-time recovery with a window from 1 to 35 days. A restore creates a new table. Confirm which settings and integrations need to be recreated before traffic can switch.

Cosmos DB supports continuous backup and periodic backup. The current continuous-backup documentation lists 7-day, 30-day, and 35-day tiers, with API-specific support and separate restore charges. The old description of a single 30-day recovery option is incomplete.

For either service, run a recovery exercise that includes application routing, permissions, and expired records. Multi-Region replication does not protect against an accidental update that is replicated everywhere.

Pricing

DynamoDB pricing uses separate read and write units. Cosmos DB pricing uses request units to represent operation cost. One RU is not equivalent to one DynamoDB read request unit or write request unit.

Compare a measured workload: point reads, writes, queries, document sizes, indexes, consistency, and regional replication. Then add storage, backups, restores, networking, and support. For DynamoDB, the pricing calculator helps translate request and item-size assumptions into an estimate.

A service with fewer operations can still cost more if each operation reads many documents or updates many indexes. Conversely, a more expensive individual operation can simplify the application enough to be worthwhile. Keep the database bill and engineering effort visible in the comparison.

When to choose each service

Choose DynamoDB when the application already runs on AWS and its key-based access paths are clear. Choose Cosmos DB for NoSQL when the application runs on Azure and benefits from its document query and consistency model. Shopping carts, games, device state, and user profiles are plausible workloads for both.

Using both is usually an integration decision for an organization with services in both clouds. Give each dataset a clear owner, replicate only the required projections, and define lag and conflict behavior. Do not introduce a cross-cloud dual-write path simply to avoid choosing a primary database.