DynamoDB and Azure Cosmos DB are the flagship managed NoSQL databases of AWS and Azure. Both are fully managed and can run serverless, partition data by key, and scale horizontally. The biggest practical differences are cloud alignment, Cosmos DB's multi-model APIs and five tunable consistency levels, and how each bills for throughput.
Should you use DynamoDB or Cosmos DB?
Choose DynamoDB if you are on AWS and want a serverless key-value and document store with pay-per-request billing and deep AWS integration. Choose Azure Cosmos DB if you are on Azure, want multi-model APIs (document, Cassandra, Gremlin graph, Table), five explicit consistency levels, or turnkey multi-region writes. Cloud alignment usually decides it before features do.
DynamoDB vs Cosmos DB at a glance
| Characteristic | DynamoDB | Azure Cosmos DB |
|---|---|---|
| Data model | NoSQL key-value and document; items up to 400 KB in tables | Multi-model; the native API for NoSQL stores JSON documents, plus wire-compatible APIs for MongoDB, Cassandra, Gremlin (graph) and Table |
| Query language / API | Native API (GetItem, Query, Scan) plus PartiQL, a SQL-compatible language |
SQL-like query language over JSON in the NoSQL API, plus each compatibility API's own query language |
| Partitioning / keys | Partition key with an optional sort key for a composite primary key | Partition key per container; items grouped into logical partitions |
| Consistency | Eventually consistent by default; strongly consistent reads available per request | Five levels — strong, bounded staleness, session, consistent prefix, eventual — chosen at the account or request level |
| Multi-region writes | Global Tables provide multi-Region, active-active replication | Turnkey global distribution; can enable multi-region writes (which precludes the strong consistency level) |
| Scaling model | Automatic partitioning; serverless on-demand or provisioned capacity | Provisioned throughput (RU/s), autoscale, or serverless; capacity measured in Request Units |
| Transactions | ACID transactions across multiple items within a Region | ACID transactions within a logical partition (e.g. transactional batch / stored procedures) |
| Pricing model | Pay-per-request (on-demand) or provisioned RCU/WCU, plus storage; AWS-only | Request Units per second (provisioned, autoscale, or serverless) plus storage, billed across every enabled region |
| Best-fit workloads | AWS-based apps with predictable key access wanting zero-ops serverless NoSQL | Azure-based apps wanting multi-model APIs, explicit consistency tuning, or global multi-write distribution |
When DynamoDB is the better choice
- You are on AWS. DynamoDB integrates natively with IAM, Lambda, Streams, and the wider AWS ecosystem, removing glue code you would otherwise write.
- You want simple pay-per-request pricing. On-demand capacity bills per read and write with no throughput to provision and no idle cost.
- Your access patterns are known and key-based. DynamoDB's partition/sort-key model delivers consistent low latency when you design keys around your queries — see single-table design.
- You want active-active multi-Region replication on AWS. Global Tables provide it as configuration.
When Cosmos DB is the better choice
- You are on Azure. Cosmos DB integrates with Azure identity, Functions, and the surrounding platform the way DynamoDB does with AWS.
- You need multi-model APIs. One service exposes document, Cassandra, Gremlin graph, and Table APIs, which can ease migrations from those ecosystems.
- You want explicit, tunable consistency. Cosmos DB offers five named consistency levels between strong and eventual — including bounded staleness and session — chosen per account or request.
- You need multi-region writes out of the box. Cosmos DB can accept writes in multiple regions with turnkey global distribution (at the cost of the strongest consistency level).
What a Cosmos DB query becomes in DynamoDB
Cosmos DB's NoSQL API has aggregate functions and a GROUP BY clause, so a status
rollup is one statement, and the SDK hands back its exact cost in the
x-ms-request-charge header:
SELECT c.status, COUNT(1) AS orders, SUM(c.amount) AS revenue
FROM orders c
WHERE c.customerId = 'acme'
GROUP BY c.status
DynamoDB has no aggregate functions and no GROUP BY, in the native API or in
PartiQL. Select: "COUNT" is the closest thing and it is a billing trap. AWS states
that counting "uses the same quantity of read units" as fetching the items, "because
DynamoDB has to read each item in order to increment the count". Both the grouping and
the summing move into your application, over items you paid full price to read.
What you give up moving off session consistency
Consistency is the bigger adjustment, and the interesting loss is the default rather
than the extremes. Session is what a Cosmos DB account starts on, and it is a mechanism
with moving parts: after a write the client caches an updated session token, sends it
back on reads, and gets read-your-writes for that session. You can hand that token to
another process, so one tier reads a write another tier just made.
DynamoDB has nothing session-shaped. ConsistentRead: true gives you the committed
value on the table or a local secondary index, and it costs double, since a strongly
consistent read of a 4 KB item is one read unit against half a unit for the eventually
consistent default. There is no token to pass and no per-session guarantee. Every call
site decides again.
Bounded staleness has no counterpart at all. Cosmos DB lets you bound lag explicitly as
K versions or T seconds, with a documented floor of 10 writes or 5 seconds on a
single-region account and 100,000 writes or 300 seconds across regions. DynamoDB
publishes no staleness bound. Global tables replicate "typically within a second",
which is an observation about normal operation rather than a contract.
The consequence that catches migrations is downstream of that. Any read you move onto a
global secondary index is eventually consistent with no override available, so the read
patterns that were quietly correct under session consistency split into two piles: go
back to the base table by key and pay for a strong read, or accept staleness you cannot
bound. Consistency stops being an account setting and becomes a key-design decision.
RU/s and read units measure different things
Request Units are a normalized currency covering CPU, IOPS and memory, which is why a
cross-partition GROUP BY has an RU price and Cosmos DB can tell you what it was.
DynamoDB read units are a function of item size and item count only, because there is
no server-side work to charge for beyond reading. The missing aggregates and the
simpler billing unit are the same absence, seen from two ends.
The two do rhyme in one place. Cosmos DB charges "a minimum of about 2.5 RUs each time
you check a physical partition's index for results even if no items in the physical
partition match", and AWS warns that a Query or Scan is billed "based on read
consistency and the number of partitions searched to serve the request, even if no data
exists". Both bill for looking, not for finding.
DynoTable's SQL Workbench is where the query at the top of this section ends up. It is
the same statement:
SELECT status, COUNT(*) AS orders, SUM(amount) AS revenue
FROM orders
WHERE customerId = 'acme'
GROUP BY status
It compiles to DynamoDB's native Query and Scan, planned against your real keys and
indexes, and performs the grouping and the sums on the client. It supports GROUP BY
plus COUNT and SUM, which PartiQL does not have. You still pay to read the items,
because that is the only thing DynamoDB charges for and no client can change it. What
it removes is the paging-and-tallying loop that would otherwise be the first thing you
write after the migration.
Working with DynamoDB
If you land on DynamoDB, DynoTable is a native desktop client for it on macOS, Windows, and Linux. It reads your standard AWS credential chain, so your data stays in DynamoDB with nothing to migrate. Beyond browsing and inline-editing items, its SQL Workbench expresses relational-shaped queries — joins, GROUP BY, aggregates — within DynamoDB's access-pattern rules by compiling them to Query/Scan, and its AI agent runs on your own AWS Bedrock credentials.
The free DynamoDB Expression Builder generates key-condition, filter, and update expressions with correct reserved-word and attribute-name handling in SDK, CLI, and PartiQL form. DynoTable is a closed-source commercial app; this page describes what it does, not how it is built.
FAQ
Is Cosmos DB the same as DynamoDB?
No. They are separate products from Microsoft and AWS. Both are managed, serverless-capable NoSQL databases that partition by key, but Cosmos DB is multi-model with several wire-compatible APIs and five consistency levels, while DynamoDB is a key-value and document store native to AWS with a two-level (eventual or strong) read model and PartiQL.
Does DynamoDB have consistency levels like Cosmos DB?
DynamoDB offers two read modes rather than five named levels: eventually consistent reads (the default) and strongly consistent reads chosen per request within a Region, plus an optional multi-Region strong consistency mode for Global Tables. Cosmos DB exposes a spectrum — strong, bounded staleness, session, consistent prefix, and eventual — configured at the account or request level.
Can I migrate from Cosmos DB to DynamoDB?
You can, but plan for remodeling rather than a lift-and-shift. Both are key-partitioned NoSQL, so the concepts transfer, but you re-map partition/sort keys and rewrite queries to DynamoDB's API or PartiQL, and any Cosmos DB Gremlin or Cassandra API usage needs a different data model on DynamoDB. Start from your access patterns — see how to model data in DynamoDB.
Related
- Learn about DynamoDB consistency and multi-Region Global Tables.
- FAQ: Is DynamoDB multi-region?
- Model access patterns with single-table design and how to model data in DynamoDB.
- Build expressions with the free DynamoDB Expression Builder.
- Download DynoTable to work with your DynamoDB tables.
References
- What is Amazon DynamoDB? — AWS DynamoDB Developer Guide
- DynamoDB read consistency
- DynamoDB global tables
- DynamoDB global tables multi-Region strong consistency — general availability
- Consistency levels in Azure Cosmos DB
- Request Units in Azure Cosmos DB
- Distribute data globally with Azure Cosmos DB
- Azure Cosmos DB: provisioned throughput vs serverless
Last verified 2026-07-13 against the official AWS DynamoDB Developer Guide and Microsoft Azure Cosmos DB documentation. Azure Cosmos DB is a trademark of Microsoft; referenced here for identification only.
Top comments (0)