Does DynamoDB support joins?

Not in the database itself. As a nonrelational database, DynamoDB has no JOIN operation, and PartiQL does not add one, so for production reads you model related data instead: denormalize (duplicate or embed it so each access pattern is one query) or use single-table design to co-locate related items under one partition key. But you can still run a real join over your DynamoDB tables from a client: DynoTable's SQL Workbench executes actual JOIN, GROUP BY, and aggregate queries over your live data.

Why the database has no join

DynamoDB is built for predictable, single-digit-millisecond reads at any scale. Joining at read time would make latency depend on how much related data exists, which breaks that guarantee. So for your modeled access patterns the join is done at write time, by you.

What happens if you try

PartiQL rejects the statement in the parser, before reading anything. Both the explicit join and the comma cross-join fail the same way:

SELECT o."total", c."name" FROM "Orders" o JOIN "Customers" c ON o."pk" = c."id"
SELECT * FROM "Orders", "Customers"

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

So there is no slow-but-working fallback to discover in production. A statement naming two tables is a syntax error, and the work has to move somewhere else: into your data model, or into a client that does the relational part itself.

What you do for modeled access patterns

Denormalization — copy or embed the related data you read together.
Single-table design — store multiple entity types in one table with overloaded keys, so an item collection reads them together in one Query.
Adjacency lists — model many-to-many relationships as items you Query by key.

These keep production reads a single request. Full walkthrough in DynamoDB joins.

Run a real JOIN with DynoTable

For the ad-hoc, cross-table question you didn't model for — "which EU customers spent over $500 last month?" across an Orders and a Customers table — DynoTable runs that join for you. It's a desktop DynamoDB client, and its SQL Workbench executes real JOIN, GROUP BY, and aggregate queries: it reads the items through the normal DynamoDB API, then runs the relational part of the query in the client. So this works, against tables that have no relationship defined and a query engine with no JOIN keyword:

SELECT   c.name, SUM(o.total) AS spend
FROM     Customers c
JOIN     Orders o ON o.customerId = c.id
WHERE    c.region = 'EU'
GROUP BY c.name

Prefer not to write SQL? Smart Tables are the visual lane for the same join engine: draw a relationship line between two tables on a canvas and browse the joined rows.

The honest caveat, "within DynamoDB's access-pattern rules": the Workbench still reads through DynamoDB, so the fastest joins are the ones whose ON attribute or WHERE clause hits a partition key or GSI on at least one side, letting DynamoDB run a Query instead of a full scan. See /docs/dynamodb-sql-workbench for Workbench behavior and /docs/smart-tables for the visual join canvas. DynoTable lets you ask the join question instead of hand-stitching results in code; it doesn't repeal the constraints above. Among DynamoDB GUI clients it's the only "yes, you can join" that is actually true: PartiQL and AWS's own NoSQL Workbench both stop at the single-table wall.

For single-table reads that avoid joins entirely, sketch overloaded keys in the single-table design tool before you model denormalized copies of related data.

The trade-off

For production read paths you do more careful work on writes to make reads cheap and constant-time.

Go deeper

Read DynamoDB joins, single-table design, and one-to-many relationships. Download DynoTable to run a real JOIN over your tables, in SQL or visually with Smart Tables.

References

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

The ValidationException above was reproduced 2026-07-28 against DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 and is quoted verbatim.