DynamoDB はリレーショナルデータベースですか？

いいえ。DynamoDB はリレーショナルデータベースではありません。NoSQL のキーバリュー兼ドキュメントストアです。固定スキーマを持つテーブルも、外部キーも、結合もありません。リレーショナル（SQL）データベースでやるように関連テーブルにまたがって正規化するのではなく、アプリケーションのアクセスパターンを中心にデータをモデル化し、非正規化します。リレーショナルなワークフローが恋しいなら、DynoTable がその一部をクライアント側で取り戻します。本物の JOIN と GROUP BY を実行する SQL Workbench と、テーブルをビジュアルに結合する Smart Table です。

リレーショナルでない理由

リレーショナルデータベースはスキーマを強制し、多数のテーブルにデータを正規化し、読み取り時にそれらを結合します。DynamoDB は逆をやります。スキーマレスなアイテムを保存し、関連データを複製または埋め込むことで、あらかじめ結合しておくことを期待します。

リレーショナル機能の代わりになるもの

結合 → 非正規化とシングルテーブル設計。
正規化されたテーブル → 1 つのパーティションキーの下にまとめられたアイテムコレクション。
アドホックな SQL → キーベースの Query と Scan、または PartiQL（SQL 互換のサブセットで、やはり結合はなし）。

ちなみに PartiQL はこのギャップを埋めません。そのパーサーは 2 テーブルの SELECT を拒否し、GROUP BY も拒否します。どちらも何かを読む前にです。正確な拒否文は DynamoDB は結合に対応しているかと DynamoDB は SQL に対応しているかに引用しています。

非正規化が実際に払わせるもの

このトレードオフはたいてい「結合する代わりにデータを複製する」と説明され、ストレージの判断のように聞こえます。実際には書き込みとアトミック性の判断であり、そここそリレーショナルエンジンがあなたから隠している部分です。

5,000 件の注文を持つ顧客がいて、その顧客が表示名を変えるとします。リレーショナルなスキーマなら 1 行に対する 1 回の UPDATE で、どの結合も即座に新しい値を拾います。DynamoDB に非正規化されていると、名前は 5,000 件すべての注文アイテムに載っているので、改名は 5,000 件のアイテム書き込みです。5,000 書き込みユニット、1 KB のアイテムなら us-east-1 のオンデマンドで約 $0.003 です。

お金は問題ではありません。問題は、それを 1 つの操作にできないことです。TransactWriteItems は 100 アクションで頭打ちなので、5,000 件は少なくとも 50 個の別々のトランザクションになり、それらの間に分離はありません。そのファンアウトが走っている間ずっと、あなた自身のデータが自分と食い違い、その最中に落ちてきた読み取りは古い名前と新しい名前の混ざったものを見ます。

リレーショナルデータベースが買ってくれるのは、まさにそこです。1 つの信頼できるコピーに対する 1 回のアトミックな変更です。それを手放すことこそが本当の入場料であり、「どの属性を複製するか」が「どの属性にインデックスを張るか」より多くの設計上の注意に値する理由です。

さらに詳しく

DynamoDB でのデータモデリング方法とシングルテーブル設計を読んでください。データモデルをビジュアルに探索し、SQL Workbench でリレーショナル的な JOIN / GROUP BY クエリを実行するには DynoTable をダウンロードしてください。

参考資料

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。100 アクションのトランザクション上限は 2026-07-28 に API リファレンスから再取得しました。