Is DynamoDB a relational database?

No. DynamoDB is not a relational database — it is a NoSQL key-value and document store. There are no tables with fixed schemas, no foreign keys, and no joins. You model data around your application's access patterns and denormalize, rather than normalizing across related tables as you would in a relational (SQL) database. If you miss the relational workflow, DynoTable brings some of it back on the client: a SQL Workbench that runs real JOIN and GROUP BY, and Smart Tables that join tables visually.

Why it is not relational

Relational databases enforce a schema, normalize data across many tables, and join them at read time. DynamoDB does the opposite: it stores schemaless items and expects you to pre-join by duplicating or embedding related data.

What replaces relational features

Joins → denormalization and single-table design.
Normalized tables → item collections grouped under one partition key.
Ad-hoc SQL → key-based Query and Scan, or PartiQL (a SQL-compatible subset, still no joins).

PartiQL does not close the gap, incidentally. Its parser rejects a two-table SELECT and rejects GROUP BY, both before reading anything; the exact refusals are quoted on does DynamoDB support joins and does DynamoDB support SQL.

What denormalizing actually costs you

The trade is usually described as "duplicate data instead of joining", which sounds like a storage decision. It is really a write and atomicity decision, and that is the part relational engines hide from you.

Take a customer with 5,000 orders, and the customer changes their display name. In a relational schema that is one UPDATE against one row, and every join picks up the new value immediately. Denormalized into DynamoDB, the name lives on all 5,000 order items, so the rename is 5,000 item writes: 5,000 write units, about $0.003 in us-east-1 on-demand at 1 KB per item.

The money is nothing. The problem is that it cannot be one operation. TransactWriteItems caps at 100 actions, so 5,000 items is at least 50 separate transactions, and there is no isolation across them. For as long as that fan-out runs, your own data disagrees with itself, and any read landing mid-flight sees a mix of old and new names.

Relational databases buy you exactly that: one atomic change to one authoritative copy. Giving it up is the actual price of admission, and it is why "which attributes get duplicated" deserves more design attention than which ones get indexed.

Go deeper

Read how to model data in DynamoDB and single-table design. Download DynoTable to explore your data model visually — and run relational-style JOIN/GROUP BY queries over it with the SQL Workbench.

References

Last verified 2026-07-13 against the official AWS documentation linked above; the 100-action transaction cap was re-fetched from the API reference on 2026-07-28.