Is DynamoDB a NoSQL database?

Yes. DynamoDB is a NoSQL database — a nonrelational, fully managed key-value and document store. It holds schemaless items rather than rows in fixed-schema tables, and trades SQL joins and ad-hoc queries for predictable single-digit-millisecond performance and horizontal scaling to virtually any size.

What kind of NoSQL

DynamoDB supports both the key-value and document data models. Every item is addressed by a primary key, and attributes can nest as maps and lists up to 32 levels deep — the document side of the model.

How it differs from SQL

No fixed schema — only the primary key is defined up front; other attributes vary per item.
No joins — you denormalize and model around access patterns instead.
Predictable performance — reads target a partition key, so latency stays flat as data grows.

What the engine does with a JOIN

PartiQL makes DynamoDB look SQL-shaped, so the boundary is easy to miss. AWS's documented SELECT syntax is the whole grammar, and it has no JOIN clause:

SELECT {{expression}}  [, ...]
FROM {{table}}[.{{index}}]
[ WHERE {{condition}} ] [ [ORDER BY {{key}} [DESC|ASC] , ...]

Send one anyway and the parser stops at the second table:

await client.send(
  new ExecuteStatementCommand({
    Statement: `SELECT o.pk FROM "orders" o JOIN "customers" c ON o.pk = c.pk`
  })
);

Real output:

ValidationException: Only select from a single table or index is supported.
HTTP 400

The refusal is at parse time, before any data is read, which is why no amount of index design gets you a join. Joining is your application's job in a NoSQL store.

It also bounds what any client can honestly offer. DynoTable's SQL Workbench accepts INNER JOIN, LEFT JOIN, GROUP BY and COUNT/SUM/AVG/MIN/MAX.

It compiles them to native Query and Scan calls, then joins and aggregates the results on your machine. DynamoDB still only ever sees single-table reads.

When it fits

DynamoDB is built for OLTP workloads: high-volume, known point-and-range reads and writes. Heavy analytics belongs in a separate columnar store fed by export.

NoSQL limits you still feel in production

"NoSQL" describes the access model, not a removal of constraints. DynamoDB still caps you at 400 KB per item, 25 actions per TransactWriteItems, and 100 read or write actions per transaction. A nested document can be 32 levels deep. GSIs project only attributes you name; there is no hidden schema to fall back on.

Those limits matter because you cannot join your way out of them at query time. You model around them up front — sparse indexes, denormalized attributes, and single-table keys — then read by partition. The Query Builder turns a filter into the Query or Scan request DynamoDB will actually execute.

In DynoTable: when a relational question is legitimate, the SQL Workbench compiles JOIN and GROUP BY down to native Query and Scan calls on your machine — DynamoDB still sees single-table reads. See SQL Workbench for the supported grammar and honest limits.

Go deeper

See when to use DynamoDB and how to shape data with how to model data in DynamoDB. Download DynoTable to browse your NoSQL tables and run SQL over them within DynamoDB's access-pattern rules.

References

Last verified 2026-07-13 against the official AWS documentation linked above; the PartiQL SELECT grammar was re-checked 2026-07-28.

Reproduced 2026-07-28 against DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 on Node v24.18.0. The ValidationException above is verbatim engine output.