When should you not use DynamoDB?

Skip DynamoDB when your workload is analytical or your access patterns are unknown. DynamoDB is purpose-built for operational (OLTP) workloads with known, key-based access patterns — it has no joins or aggregate functions, and ad-hoc queries fall back to expensive full-table scans. For OLAP reporting or evolving relational needs, pick a different engine.

Poor fits

Ad-hoc analytics and reporting (OLAP) — there's no GROUP BY, SUM, or AVG; every rollup is a scan or a pre-computed aggregate you maintain yourself. See the aggregation guide for the workarounds.
Normalized relational schemas — DynamoDB deliberately omits the JOIN operator; AWS's own guidance is to denormalize. If your model genuinely needs many-way joins at read time, a relational engine fits better — compare directly in DynamoDB vs PostgreSQL.
Unknown or fast-evolving access patterns — you design the keys around the queries. When you can't name the queries yet, every new one risks a table redesign or a full scan.
Full-text search and rich querying — see does DynamoDB support full-text search?; search belongs in a search index.
Large objects — items cap at 400 KB; media and documents belong in S3 with a pointer in the table.

Where it shines

The inverse list is exactly DynamoDB's sweet spot: high-volume operational workloads with predictable key-based reads and writes that must stay single-digit-millisecond at any scale — carts, sessions, profiles, game state, IoT events. The when to use DynamoDB guide makes the positive case, and the DynamoDB vs. comparisons walk through the head-to-heads.

Go deeper

If you're on the fence, read when to use DynamoDB next. Already on DynamoDB and missing SQL? DynoTable runs JOIN and GROUP BY against live tables from the desktop — and the pricing calculator tells you what your workload would cost before you commit.

References

Last verified 2026-07-13 against the official AWS documentation linked above.