DynamoDB は JOIN に対応していますか？

データベース自体では対応していません。非リレーショナルデータベースである DynamoDB に JOIN 操作はなく、PartiQL もそれを足しません。そのため本番の読み取りでは、関連データをモデリングで扱います。非正規化する（複製または埋め込んで、各アクセスパターンを 1 クエリにする）か、シングルテーブル設計で関連アイテムを 1 つのパーティションキーの下に同居させるかです。とはいえ、クライアントから DynamoDB のテーブルに対して本物の結合を実行することはできます。DynoTableの SQL Workbench は、稼働中のデータに対して実際の JOIN、GROUP BY、集計クエリを実行します。

データベースに結合がない理由

DynamoDB は、どんな規模でも予測可能な 1 桁ミリ秒の読み取りのために作られています。読み取り時に結合すると、レイテンシが関連データの量に依存してしまい、その保証が壊れます。ですから、モデリング済みのアクセスパターンについては、結合は書き込み時にあなた自身が行います。

試すとどうなるか

PartiQL は、何かを読み取る前にパーサーの段階でその文を拒否します。明示的な結合も、カンマによるクロス結合も、同じように失敗します。

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

つまり、本番で見つかる「遅いけれど動く」フォールバックは存在しません。2 つのテーブルを指定した文は構文エラーであり、その仕事はどこか別の場所 — データモデルの中か、リレーショナルな部分を自前でこなすクライアントの中 — に移すしかありません。

モデリング済みのアクセスパターンでやること

非正規化 — 一緒に読む関連データをコピーまたは埋め込みます。
シングルテーブル設計 — キーをオーバーロードして複数のエンティティ型を 1 つのテーブルに格納し、アイテムコレクションが 1 回の Query でまとめて読めるようにします。
隣接リスト — 多対多の関係を、キーで Query できるアイテムとしてモデリングします。

これらは本番の読み取りを 1 リクエストに保ちます。詳しい手順は DynamoDB の JOINにあります。

DynoTable で本物の JOIN を実行する

モデリングして いなかった その場限りのテーブル横断の問い — Orders テーブルと Customers テーブルにまたがる「先月 500 ドル以上使った EU の顧客は？」 — に対して、DynoTableはその結合を実行します。デスクトップの DynamoDB クライアントで、その SQL Workbench は本物の JOIN、GROUP BY、集計クエリを実行します。通常の DynamoDB API を通じてアイテムを読み、クエリのリレーショナルな部分をクライアント側で実行するのです。ですから、関係が定義されていないテーブルと、JOIN キーワードを持たないクエリエンジンに対して、これが動きます。

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

SQL を書きたくないですか？ スマートテーブル は、同じ結合エンジンのビジュアル版です。キャンバス上で 2 つのテーブルのあいだに関係の線を引けば、結合された行を閲覧できます。

正直な但し書き、つまり「DynamoDB のアクセスパターンのルール内で」という条件はこうです。Workbench も依然として DynamoDB を通じて読むので、いちばん速い結合は、ON の属性か WHERE 句が少なくとも片側でパーティションキーか GSIに当たり、DynamoDB がフルスキャンではなく Query を実行できるものです。Workbench の挙動については /docs/dynamodb-sql-workbench、ビジュアルな結合キャンバスについては /docs/smart-tables を参照してください。DynoTable は、結果をコードで手作業でつなぎ合わせる代わりに結合の問いを 投げられる ようにするだけで、上記の制約を撤廃するわけではありません。DynamoDB の GUI クライアントの中で、「はい、結合できます」が本当に成り立つのはこれだけです。PartiQL も AWS 自身の NoSQL Workbench も、単一テーブルの壁で止まります。

結合をまったく使わずに済むシングルテーブルの読み取りについては、関連データの非正規化したコピーをモデリングする前に、シングルテーブル設計ツールでオーバーロードしたキーを下書きしてみてください。

トレードオフ

本番の読み取り経路では、読み取りを安く一定時間にするために、書き込み側でより丁寧な作業をします。モデルが本当に全面的にリレーショナルな結合を必要とするなら、リレーショナルエンジンの方が合うかもしれません。

さらに詳しく

DynamoDB の JOIN、シングルテーブル設計、DynamoDB の 1 対多の関係を読んでください。自分のテーブルに対して SQL で、あるいはスマートテーブルで視覚的に本物の JOIN を実行するには、DynoTable をダウンロードしてください。

参考資料

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。

上記の ValidationException は 2026-07-28 に、@aws-sdk/client-dynamodb 3.1095.0 を用いて DynamoDB Local 3.3.0 に対して再現したもので、そのままの逐語です。