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

部分的には対応しています。DynamoDB は SELECT、INSERT、UPDATE、DELETE 文のための SQL 互換のクエリ言語 PartiQL をサポートします。ただし完全な SQL ではありません。JOIN はなく、GROUP BY もなく、任意の集計もできませんし、効率的なクエリには依然としてプライマリキーかインデックスを狙う必要があります。その欠けている部分が欲しいなら、DynoTable の SQL Workbench が本物の JOIN、GROUP BY、集計クエリを DynamoDB テーブルに対してデスクトップから実行します。

PartiQL が与えてくれるもの

4 つのデータ操作のための、見慣れた SQL 構文です。低レベルの API 呼び出しを組み立てる代わりに SELECT * FROM "Orders" WHERE ... と書けます。便利で読みやすい構文です。

与えてくれないもの

JOIN なし — DynamoDB は非リレーショナルです。代わりに非正規化します。
GROUP BY / 集計なし — グループ化と合計はアプリケーション側で行います。
自由なスキャンが安いわけではない — キー条件のない SELECT は依然として Scan を実行し、それなりのコストがかかります。

パーサーが止まる場所

これらは構文を変えれば届く機能ではありません。実行しても、文はアイテムを読むところまで到達しません。

SELECT "region", SUM("total") FROM "Orders" GROUP BY "region"
  ValidationException: Unsupported clause: GROUP BY

SELECT COUNT(*) FROM "Orders"
  ValidationException: Unexpected path component at 1:8:5

SELECT SUM("total") FROM "Orders"
  ValidationException: Unexpected path component at 1:8:3

SELECT DISTINCT "region" FROM "Orders"
  ValidationException: Unsupported token in expression: DISTINCT

集計のエラーが何と言っているかを見てください。パーサーが断るべき集計関数がそもそも存在しないので、COUNT(*) は属性パスとして読まれ、8 桁目の * で倒れます。SQL の表面はそれほど薄いのです。

ORDER BY は知っておくべきものです。動きそうに見えるからです。

SELECT * FROM "Orders" WHERE "pk" = 'U#1' ORDER BY "total"
  ValidationException: Variable reference total in ORDER BY clause must be part of the primary key

並べ替えられるのはソートキーで昇順か降順のみ、それ以外はできません。他の属性での並べ替えは、読み取りの後にアプリケーションがやる仕事です。

メンタルモデル

PartiQL は、DynamoDB の既存の Query、Scan、書き込み操作の上に乗った構文レイヤーだと考えてください。下では同じアクセスパターンのルールが適用されます。

DynoTable による本物の SQL（JOIN、GROUP BY、集計）

PartiQL は単一テーブルの SELECT で止まります。DynoTable の SQL Workbench はその先へ進みます。DynamoDB テーブルに対して実際の JOIN、GROUP BY、集計関数（COUNT、SUM、AVG、MIN、MAX）を実行します。アイテムは通常の DynamoDB API を通して読み、クエリのリレーショナルな部分をクライアント側で実行します。つまり DynamoDB のアクセスパターンのルール内での SQL です。どの結合も本物のキーかインデックスを通して読むからです。こうして PartiQL にできない 3 つのことを、1 つの文として書けます。

SELECT   c.region, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM     Orders o
JOIN     Customers c ON o.customerId = c.id
GROUP BY c.region

下層の制約については正直なままです（境界のない結合は境界のない読み取りです）。ですから最速のクエリは、その結合や WHERE がパーティションキーやインデックスに当たるものです。詳細は SQL for DynamoDBと、製品マニュアルの /docs/dynamodb-sql-workbenchにあります。

同じデータモデルの PartiQL 側は、DynamoDB クエリビルダーで試作できます — キー条件があるときに PartiQL の SELECT が通る効率的な経路に乗ったまま、パーティションに絞った Query プログラムを出力します。

さらに詳しく

両者は PartiQL vs SQLで比較し、PartiQL の例を見て、SQL for DynamoDBを読んでください。自分のテーブルに対して PartiQL と、本物の JOIN、GROUP BY、集計を書くには DynoTable をダウンロードしてください。

参考資料

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

上記の ValidationException はすべて 2026-07-28 に @aws-sdk/client-dynamodb 3.1095.0 経由で DynamoDB Local 3.3.0 に対して再現したもので、桁位置も含めて逐語で引用しています。