Is DynamoDB or Aurora right for my workload?
Amazon DynamoDB is a fully managed NoSQL key-value and document store built for
single-digit-millisecond performance at any scale, with no fixed schema. Amazon
Aurora is a managed relational database that's compatible with MySQL and
PostgreSQL, using full SQL with tables, joins, and ACID transactions. Choose
DynamoDB for high-scale key-value access; choose Aurora for relational queries.
DynamoDB vs Amazon Aurora at a glance
| Characteristic | DynamoDB | Amazon Aurora |
|---|---|---|
| Data model | NoSQL key-value and document store; schemaless (only the primary key is required) | Relational: structured tables, rows, and columns with a defined schema and relationships |
| Query language | AWS SDK/API operations plus PartiQL, a SQL-compatible query language for select/insert/update/delete | Full SQL, compatible with MySQL or PostgreSQL |
| Joins | No server-side joins; you model access patterns up front (often single-table design) | Native SQL JOIN across tables via the relational engine |
| Indexes | Local and global secondary indexes (LSI / GSI) | Standard relational indexes (primary and secondary) provided by MySQL/PostgreSQL |
| Consistency | Eventually consistent reads by default; strongly consistent reads available per request | Strong consistency with full relational integrity |
| Scaling | Scales out horizontally across partitions; no upper limit on items per table or table size; on-demand or provisioned capacity | Cluster of a writer plus up to 15 low-latency read replicas across three Availability Zones; storage auto-grows to 256 TiB; Aurora Serverless v2 auto-scales capacity |
| Transactions | ACID transactions of up to 100 items (4 MB aggregate) within a single Region | Full multi-statement ACID transactions |
| Pricing model | On-demand or provisioned capacity (read/write units) plus storage | Instance capacity (On-Demand or Reserved) or Aurora Serverless v2, plus storage and I/O |
| Best fit | Web-scale key-value/document workloads, predictable low latency | Relational workloads needing joins, complex queries, and SQL familiarity |
When DynamoDB is the better choice
DynamoDB fits when your access patterns are known and key-based, and you need
predictable single-digit-millisecond latency as traffic grows. Per the AWS
DynamoDB Developer Guide, it's designed to scale out on distributed hardware with
no upper limit on the number of items or total table size, which suits web-scale
applications such as social networks, gaming, media sharing, and IoT. It's a good
match when you want a serverless operational model with no instances to size, and
when a flexible, semi-structured item shape (including JSON) is an advantage. If
your workload is intermittent or key-value in nature, DynamoDB's per-request
model lets cost track usage closely.
When Aurora is the better choice
Aurora fits relational workloads: data with real relationships, complex ad hoc
queries, joins, aggregations, and reporting where SQL is the natural tool. Because
Aurora is MySQL- and PostgreSQL-compatible, existing SQL code, tools, and ORMs
generally work with little change, and teams already productive in SQL keep their
skills. Aurora is a strong choice when strong consistency and relational integrity
across many related tables matter, or when you need multi-statement transactions
that span a rich schema. AWS also notes the two are often complementary — for
example, DynamoDB on the hot path and Aurora for the analytical or reporting path.
What an Aurora Serverless v2 spike becomes in DynamoDB
Both sides auto-scale, so the question engineers actually agonize over is what
each one scales. The units are different, and the difference decides which
workloads move across cleanly.
A tournament leaderboard makes it concrete. On Aurora it is unremarkable SQL:
SELECT player_id, score
FROM leaderboard_entries
WHERE tournament_id = 91744
ORDER BY score DESC
LIMIT 100
Aurora Serverless v2 scales that in Aurora capacity units. One ACU is roughly
2 GiB of memory with matching CPU and networking, the range runs from 0.5 to 256
ACUs (0 if you enable automatic pause), and it adds or removes half an ACU at a
time. AWS dropped the v2 from the documentation in April 2026; the mechanism is
unchanged.
So Aurora scales the machine. Growing a provisioned cluster means standing up a
whole new DB instance, while Serverless v2 grows the writer you already have.
Either way, the row for tournament 91744 has no throughput quota of its own.
DynamoDB scales the partition. On-demand mode also has no capacity to set, and it
instantly absorbs up to double a table's previous peak, with new tables starting
at around 4,000 writes and 12,000 reads per second. Throughput is capped per
partition key value at 3,000 RCU and 1,000 WCU, and that cap holds however much
capacity the table has.
Every read of this leaderboard uses one partition key value. With tournamentId
as a GSI partition key and score as its sort key, the top 100 is one request:
{
"TableName": "leaderboard_entries",
"IndexName": "tournament-score-index",
"KeyConditionExpression": "tournamentId = :t",
"ExpressionAttributeValues": {":t": {"N": "91744"}},
"ScanIndexForward": false,
"Limit": 100
}
Raising the ceiling on that request is a data-model change rather than a capacity
setting. You shard the key into 91744#0 through 91744#9, query all ten, and
merge the results yourself.
Writes carry their own tax. score is the index sort key and it moves every time
somebody scores, which is why AWS suggests provisioning a GSI whose keys change
often at roughly 1.5 times the base table's write units.
Two more limits belong in the comparison. The ordering only holds inside one
partition key value, so a global top 100 across every tournament is a Scan. And
growth beyond double the previous peak within 30 minutes can throttle, so a
launch you can predict is one you pre-warm with warm throughput. On Aurora
Serverless v2 you would raise the maximum ACU and stop thinking about it.
DynoTable's SQL Workbench covers the reporting half of what you would have kept
Aurora for:
SELECT p.country, SUM(e.score) AS total
FROM leaderboard_entries e
JOIN players p ON e.playerId = p.playerId
GROUP BY p.country
It compiles to DynamoDB's own Query and Scan operations, planned against your
real keys and indexes, and joins and aggregates on the client. It supports
INNER JOIN, LEFT JOIN, GROUP BY, COUNT and SUM, and PartiQL supports
none of those.
To be honest about the scaling point above, it reads through those same
operations and inherits the same per-partition ceilings, so it buys you no extra
throughput. It does not add a server-side join to DynamoDB, because nothing can.
What it removes is the pagination loop and the client-side rollup.
Working with DynamoDB
Once you've chosen DynamoDB, DynoTable is a desktop DynamoDB client
for browsing, editing, and querying tables without the AWS Console. Because
DynamoDB has no server-side joins, its SQL Workbench expresses relational-shaped
queries — joins, GROUP BY, aggregates — within
DynamoDB's access-pattern rules by compiling them down to DynamoDB's own
Query/Scan operations, and an AI agent runs on your own AWS Bedrock
credentials so your schema and data stay in your account. So the ad-hoc reporting
question you'd have kept Aurora for is still one SELECT away. For quick one-off
queries, the free
DynamoDB Expression Builder helps you compose
key conditions, filter expressions, and projections and emit the matching SDK, CLI,
or PartiQL code. DynoTable is a closed-source commercial application; it reads your
standard AWS credentials and talks to DynamoDB directly, so there's nothing to
migrate when you switch from another client.
FAQ
Is DynamoDB cheaper than Aurora?
It depends on the workload — neither is universally cheaper. DynamoDB bills for
on-demand or provisioned read/write capacity plus storage, so cost tracks request
volume and can approach zero when idle. Aurora bills for instance capacity (or
Aurora Serverless v2) plus storage and I/O. For intermittent, key-value traffic
DynamoDB's per-request model often costs less; for sustained, high-volume
relational workloads a provisioned Aurora cluster can be more economical. Model
your own read/write patterns before deciding.
Aurora vs DynamoDB for serverless apps?
Both offer serverless-style operation, so the deciding factor is the data model,
not the billing model. DynamoDB is serverless by design — no instances to manage,
capacity that scales automatically, and per-request pricing — which suits key-value
and document access at scale. Aurora Serverless v2 auto-scales a relational engine
(and can scale to zero when idle), which suits serverless apps that genuinely need
SQL, joins, and relational integrity. Pick DynamoDB for key-value access patterns
and Aurora when your app is fundamentally relational.
Related
- Learn: When to use DynamoDB · SQL for DynamoDB · DynamoDB JOIN · PartiQL vs SQL
- Build queries fast with the free DynamoDB Expression Builder.
- Download DynoTable for macOS, Windows, or Linux.
References
- Choosing between relational (SQL) and NoSQL — AWS DynamoDB Developer Guide
- Amazon DynamoDB transactions
- DynamoDB on-demand capacity mode
- What is Amazon Aurora?
- Amazon Aurora storage and reliability (256 TiB cluster volume)
- Aurora Serverless v2
- Compare Amazon Aurora and Amazon DynamoDB — AWS
Last verified 2026-07-13 against the AWS DynamoDB Developer Guide and Amazon
Aurora documentation. Amazon DynamoDB, Amazon Aurora, MySQL, and PostgreSQL are
trademarks of their respective owners; referenced here for identification only.
Top comments (0)