When to Use DynamoDB (and When Not To)

DynamoDB is a fantastic database for the workloads it's built for and a frustrating
one for the rest. The deciding question is "do I know
my access patterns up front, and are they key-based?" Get that right and DynamoDB
gives you single-digit-millisecond reads at any scale; get it wrong and you'll fight
the lack of joins and ad-hoc queries forever.

When should I use DynamoDB?

Use DynamoDB when your access patterns are known, key-based, and high-volume, and you
want predictable single-digit-millisecond latency at any scale with zero servers to
manage. Avoid it for ad-hoc queries, rich joins, or whole-dataset analytics, and when
the data is small with query shapes that keep changing.

• Use DynamoDB when your access patterns are known, key-based, and high-volume — and you want predictable latency at any scale with no servers to manage.
• Avoid it when you need ad-hoc queries, rich joins, or analytics over the whole dataset, or when the data is small and the query shapes keep changing.
• The core trade: DynamoDB makes you design for your queries up front; in return it never slows down as you grow.
• It is not a relational database with a different syntax — modeling it like one is the #1 source of pain.

The signals that favor DynamoDB

DynamoDB shines when most of these hold:

• You know your access patterns in advance. You can list the exact queries the app makes ("get a user by id", "list a user's orders newest-first") and they don't change on a whim. DynamoDB is modeled around those queries.
• Access is key-based. You look items up by a known partition key, not by scanning for arbitrary attribute combinations.
• Scale and predictable latency matter. DynamoDB delivers consistent single-digit-millisecond performance whether the table holds a thousand items or a billion.
• You want zero operational overhead. No instances, no failover, no vacuuming — it's fully managed and scales to zero on-demand.
• Write throughput is high and spiky. Event logs, IoT telemetry, session/cart state, leaderboards — append-heavy workloads with a clear key.

The signals against it

Reach for a relational database (or a search/analytics engine) instead when:

• Your queries are ad-hoc. Analysts slice the data by arbitrary columns, or requirements change weekly. SQL's flexibility wins; DynamoDB would need a new index per pattern.
• You need real joins and aggregations across the whole dataset. Reporting, business intelligence, "sum revenue by region by month" — that's an OLAP/relational job. (The one-off question against a live table is a different case — DynoTable's SQL Workbench runs JOIN, GROUP BY, and aggregates over DynamoDB client-side; it's the standing BI workload that belongs elsewhere.)
• The dataset is small and low-traffic. A few thousand rows on a quiet admin app gets no benefit from DynamoDB's scale and loses SQL's convenience.
• You can't predict access patterns yet. Early-stage product still finding its shape? A relational schema you can re-query freely is more forgiving until the patterns settle.

How DynamoDB compares to other databases

"Should I use DynamoDB or X?" is usually the same question in different clothes: does X
let me postpone the access-pattern decision, and what do I pay for that? DynamoDB is
the option that refuses to let you postpone it. Every comparison below turns on that one
trade, not on feature checklists.

Relational: PostgreSQL, RDS, and Aurora

This is the real fork, and the one most teams get wrong. A relational database lets you
write the query after you have the data. DynamoDB does not — the table is shaped by the
queries before a single item is written.

Pick relational when the query shapes are still moving, when you need joins or
aggregates across the whole dataset, or when the data is small enough that scale is not
the problem you have. Pick DynamoDB when the patterns are settled and key-based and you
want them to cost the same at a billion items as at a thousand.

RDS and Aurora do not change that calculus — they are managed relational engines, so
they inherit SQL's flexibility and its scaling model. What they change is the operational
comparison: with Aurora Serverless the "no servers to manage" argument for DynamoDB gets
much weaker, and the decision falls back cleanly onto access patterns. Aurora scales
compute; DynamoDB removes the concept.

Document: MongoDB and DocumentDB

Both store JSON-ish documents, so they look interchangeable with DynamoDB from a distance.
They are not. MongoDB indexes any field and runs ad-hoc queries against it; DynamoDB gives
you the partition key, the sort key, and the indexes you declared in advance.

That makes MongoDB the better fit for evolving query shapes, and DynamoDB the better fit
for known ones at high volume. DocumentDB sits on the AWS side of the same line — it
speaks the MongoDB API, so treat it as "MongoDB's flexibility, AWS's operational model",
and compare it to DynamoDB on exactly the flexibility-versus-predictability axis above.

Wide-column: Cassandra

Cassandra is DynamoDB's closest architectural relative: partition key, clustering
key, and the same hard truth that a bad partition key is a design bug you cannot index
your way out of. If you are choosing between them, the deciding factors are rarely the
data model — they are who runs it and how you pay. Cassandra you operate (or buy managed);
DynamoDB you consume. Amazon Keyspaces is the managed-Cassandra middle ground.

Because the models are so close, the modeling guidance on this site mostly transfers: the
single-table design reasoning about partition keys
and access patterns applies to Cassandra almost line for line.

In-memory: Redis

Redis and DynamoDB solve different problems. Redis is memory-first and optimized for sub-millisecond access to
data you can afford to lose or rebuild; DynamoDB is durable by default. The common
production answer is both — DynamoDB as the system of record, Redis (or DAX, which is
DynamoDB's own read-through cache) in front of the hot keys.

Reach for Redis alone only when the data is genuinely ephemeral: rate-limit counters,
short-lived sessions, leaderboards you can recompute.

Search: Elasticsearch and OpenSearch

Search and DynamoDB solve different problems too — for a sharper reason than Redis: DynamoDB has no full-text
search at all. Query matches on key equality and a narrow set of sort-key conditions.
Scan with a FilterExpression reads every item and then discards most of them — it is a
table walk with a filter bolted on, not a search, and you pay for the items read rather than
the items returned. There is no relevance ranking, no analyzers, no fuzzy matching, no
faceting.

So the question is never "DynamoDB or a search engine". It is "does this workload need
search, and if so, what feeds the index?" The standard shape is both: DynamoDB as the system
of record, a search cluster alongside it, and DynamoDB Streams carrying every change into the
index. That buys real search and costs you a second system to run and an index that is
eventually consistent with the table.

OpenSearch and Elasticsearch are the same decision. OpenSearch is AWS's fork of
Elasticsearch, split at 7.10 in 2021 over Elastic's licence change, and the two have drifted
apart since. None of that drift touches this question — for "should the search live outside
DynamoDB", they behave identically. Choose between them on licensing, hosting and which
managed service you want to operate, not on anything to do with DynamoDB.

Reach for a search engine as the primary store only when search genuinely is the product —
log analytics, a catalogue whose main access pattern is free-text. Even then, most teams keep
a durable store behind it, because a search index is a derived view you need to be able to
rebuild.

The cost axis, which the model comparison hides

Every comparison above is about data models, but the surprise on the bill is usually
structural: relational engines bill for capacity you provision, DynamoDB bills for
operations you perform. That makes DynamoDB cheap for spiky and idle workloads and
expensive for sustained scanning — the same workload can win on one engine and lose badly
on the other with no code change between them.

The multiplier people miss is indexes. On a relational engine an extra index costs storage
and some write latency; on DynamoDB every secondary index is a full extra write of the
projected attributes. We worked the arithmetic out at three write volumes in
the indexes guide — one GSI doubles the write bill, two triple
it. Model your real read/write mix in the
pricing calculator before you commit to either side.

Counting the cost before you commit

DynamoDB pricing follows reads, writes, and storage — not instance hours — so it's
cheap for spiky and serverless workloads and can be pricey for sustained heavy scans.
Model your real read/write mix with the
DynamoDB pricing calculator before committing;
a workload that looks like a fit technically should also pencil out on cost.

Once you've decided it fits

The work shifts to modeling. DynamoDB rewards designing the table around your queries
— see how to model data in DynamoDB and
single-table design — and explicitly
when not to reach for single-table.

Pitfalls + next steps

• Don't model DynamoDB like a relational database — normalized tables you join at read time is the anti-pattern it punishes hardest.
• Don't pick it for analytics — pair it with an analytics store (or export to one) for reporting instead of scanning.
• Unsure about access patterns? Wait. Adopting DynamoDB before you know your queries is choosing the one database that demands you know them.
• Related: query vs scan shows what "key-based access" actually buys you.

Want to explore a DynamoDB table before betting your app on it?
Download DynoTable and connect to your data directly — its
SQL Workbench runs the ad-hoc JOINs and aggregates
DynamoDB itself won't.