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.
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.

The rollup, refused and then priced

The analytics misfit is not a matter of taste. Ask DynamoDB for a grouped count in PartiQL and the statement is rejected before it reads anything:

SELECT status, COUNT(*) FROM "orders" GROUP BY status

ValidationException: Unsupported clause: GROUP BY
HTTP 400

Drop the grouping and ask for the plain total, and it fails one step earlier, in the parser:

SELECT COUNT(*) FROM "orders"

ValidationException: Unexpected path component at 1:8:5
HTTP 400

COUNT is not a function in this dialect at all, so the parser reads it as an attribute path and gives up at the bracket.

That leaves the Scan you write yourself, and it has a price. Reading a 50 GB table end to end costs 6,553,600 eventually consistent read units, which is the aggregate scanned size in 4 KB units, halved. In us-east-1 on-demand that is $0.82.

Refresh that one number hourly and it is $598 a month. Maintaining the counter as you write, or exporting to an analytics store, is the cheaper answer, and both are work DynamoDB is not doing for you.

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.

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. The 400 KB figure was re-confirmed 2026-07-28; AWS has moved it from the service-quotas page into Constraints.html.

Reproduced 2026-07-28 against DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 on Node v24.18.0; both ValidationException messages are verbatim. The Scan cost is computed from the us-east-1 rates in our synced AWS pricing table.