DynamoDB を使うべきでないのはどんなときですか？

ワークロードが分析的である場合、またはアクセスパターンが未知の場合は DynamoDB を避けましょう。DynamoDB は、既知のキーベースのアクセスパターンを持つ運用 (OLTP) ワークロード向けに構築されています。結合も集計関数もなく、アドホッククエリは高コストなフルテーブルスキャンにフォールバックします。OLAP レポーティングや進化するリレーショナルなニーズには、別のエンジンを選びましょう。

適さない用途

アドホックな分析とレポーティング (OLAP) — GROUP BY、SUM、AVG はありません。すべての集計は、スキャンか、自分で維持する事前計算された集計です。回避策については集計ガイドを参照してください。
正規化されたリレーショナルスキーマ — DynamoDB は意図的に JOIN 演算子を省いています。AWS 自身のガイダンスは非正規化することです。モデルが本当に読み取り時の多方向結合を必要とするなら、リレーショナルエンジンの方が適しています。DynamoDB vs PostgreSQL で直接比較しましょう。
未知または急速に進化するアクセスパターン — キーはクエリを中心に設計します。まだクエリを挙げられないとき、新しいクエリのたびにテーブルの再設計やフルスキャンのリスクが生じます。
全文検索と豊富なクエリ — DynamoDB は全文検索をサポートしていますか？を参照してください。検索は検索インデックスに属します。
ラージオブジェクト — アイテムは 400 KB で上限に達します。メディアやドキュメントは、テーブルに参照を置いて S3 に属します。

得意な領域

その逆のリストが、まさに DynamoDB のスイートスポットです。あらゆる規模で1桁ミリ秒を保たなければならない、予測可能なキーベースの読み取り・書き込みを持つ大量の運用ワークロードです。カート、セッション、プロフィール、ゲームの状態、IoT イベントなどです。DynamoDB をいつ使うべきかのガイドが肯定的な論拠を示し、DynamoDB vs 比較が対決を1つずつ解説します。

さらに詳しく

迷っているなら、次にDynamoDB をいつ使うべきかをお読みください。すでに DynamoDB を使っていて SQL が恋しいですか？ DynoTable は、デスクトップからライブテーブルに対して JOIN と GROUP BY を実行します。そして料金計算ツールが、コミットする前に自分のワークロードのコストを教えてくれます。

参考資料

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