Amazon Aurora DSQL 入門 — 分散SQLの使いどころと移行前に押さえる制約5点

「マルチリージョンで強整合、しかも運用ゼロの分散SQL」と聞くと、魅力的に感じる方は多いと思います。それを実現しようとしているのが、2025年5月にGA（一般提供開始）した Amazon Aurora DSQL です。PostgreSQL互換をうたう、サーバーレスの分散SQLデータベースです。「分散SQL」とは、複数のノード（やリージョン）にデータを分散させながら、SQLで一貫した読み書きができるデータベースを指します。

ただ、名前に「Aurora」と付いてはいますが、これは通常のAuroraの上位版でも単純な置き換えでもありません。別系統のアーキテクチャを持つ専用サービスで、その分散の代償としていくつかの制約があります。この記事では、通常のAuroraとの違い、料金、使い分け、そして移行前に必ず押さえておきたい制約まで、採用・移行の判断材料として実務目線で整理してみましょう。

Aurora DSQL とは — 通常のAuroraと何が違うか

Aurora DSQL は、PostgreSQL互換のサーバーレス分散SQLデータベースです。「PostgreSQL互換」というのは、標準のwireプロトコル（クライアントとDBの通信規約）に対応しているという意味で、既存のドライバやORM、SQLの多くがそのまま使えます。

では、通常の Aurora（Aurora PostgreSQL や Serverless v2）と何が違うのか。いちばんの違いはアーキテクチャそのものです。Aurora DSQL は内部コンポーネントを**分離（disaggregated＝従来一体だった機能を切り離して別々に拡張できるようにする考え方）**して独立にスケールさせます。これにより、マルチリージョンでの強整合（strong consistency）――どのリージョンから読み書きしても常に最新の一貫した結果が返る状態――を低レイテンシで実現しています。これは通常のAuroraがネイティブには提供しないものです。

可用性も高く設計されており、単一リージョンで99.99%、マルチリージョン構成（2つのピアクラスタ＋witnessリージョン）で99.999%とされています。

ここで強調しておきたいのは、Aurora DSQL は「分散ワークロード向けの専用オファリング」であって、Aurora PostgreSQL の単純な置き換えではないということです。後述する制約を受け入れられる設計でこそ活きます。この前提を外すと、移行でつまずきます。

移行前に押さえる制約5点 — ここが記事の核

「PostgreSQL互換」と聞くと「既存のものがそのまま動く」と思いがちですが、全機能互換ではありません。既存アプリの移行を検討するなら、まず次の5点を自分のアプリと突き合わせてください。移行チェックリストとして使える形に表でまとめます。

制約	内容	実務での対応
① OCC（楽観的同時実行制御）	ロックを取らず、コミット時に競合を検出。競合時はシリアライゼーションエラーを返す（デッドロックは発生しない）	アプリ側にリトライ処理が必須。冪等（同じ処理を何度実行しても結果が同じ）なトランザクション設計を前提に
② 1トランザクション最大3,000行	INSERT/UPDATE/DELETE の合計変更行数の上限（セカンダリインデックス数に関わらず）	大量更新はバッチを分割。数千行超の一括処理は不向き
③ DDLとDMLの分離	DDL（定義変更）とDML（データ操作）は別トランザクション。1トランザクションにDDLは1文まで	マイグレーションの組み方を見直す
④ 接続は1時間でタイムアウト	データベース接続が1時間で切れる	長時間接続前提の処理は再接続設計に。コネクションプールの扱いに注意
⑤ 非対応機能	PL/pgSQL等の手続き型言語・トリガー・外部キー（参照整合性）・一時テーブルが非対応	ロジックはアプリ層やLambdaへ、イベント駆動はEventBridge等へ、参照整合性はアプリ層で実装

「OCC（楽観的同時実行制御）」は、競合がめったに起きない前提でロックを省き、コミット時にだけ衝突を確かめる方式です。「DDL」はテーブル定義などの変更、「DML」はデータの挿入・更新・削除を指します。

このほかにも知っておきたい差異があります。1クラスタに持てるデータベースは postgres の1つのみ（論理分離はスキーマか別クラスタで）、TRUNCATE は非対応で DELETE FROM を使う、インデックス作成は無停止の CREATE INDEX ASYNC、分離レベルは Repeatable Read 固定、連番の SERIAL は分散環境に不向きなため UUID やアプリ生成IDが推奨、といった点です。これらの制約値や非対応機能は更新されることがあるため、移行設計の前に公式のConsiderations / 互換性ドキュメントで最新を確認してください。

料金 — DPU＋ストレージ、アイドル時はゼロ

料金の課金軸は2つです。ひとつは DPU（Distributed Processing Unit）、もうひとつは**ストレージ（GB-月）**です。

DPU は、SQL処理の総仕事量を測る単位です。クエリ実行のコンピュート、ストレージI/O、CDC（変更データのストリーミング）などを合算したもので、CloudWatch に ComputeDPU / ReadDPU / WriteDPU などの内訳が出ます。サーバーレスらしく、アイドル時は自動でゼロにスケールし、DPU課金は発生しません。さらに、毎月最初の10万DPUと1GBストレージは無料枠として自動適用されます。マルチリージョン書き込みでは、ピアクラスタへのレプリケート分に、元の書き込みと同等の追加DPU課金がかかります。

参考単価（米国東部オハイオの例）は、DPU が $8 / 100万DPU、ストレージが $0.33 / GB・月です。ただしこれらは2026年6月時点の参考値で、リージョン差や改定がありえます。見積もり時は必ず公式の料金ページで確認してください。

ひとつ注意したいのは、DPU は「処理量」に対する課金なので、見積もりが直感的ではない点です。「インスタンスを何時間動かすといくら」という従来の感覚は通用しにくく、クエリの効率（無駄なスキャンを減らす、カバリングインデックスでindex-only scanにするなど）がそのままコストに効きます。設計段階で意識しておきたいところです。

他のデータベースとの使い分け

「分散SQLだから何にでも使える」わけではありません。代表的な3つの選択肢を並べてみます。なお、スループットやレイテンシ、価格の定量的な横断比較は公式に示されていないため、ここでは数値での優劣は断定せず、向く場面の軸でお伝えします。

選択肢	向く場面（定性軸）
Aurora DSQL	サーバーレスで運用ゼロ、マルチリージョン強整合・アクティブアクティブ、ほぼ無限スケール、断続的・予測不能な負荷（アイドルでゼロ）。OCC・3,000行制約・一部PostgreSQL機能の非対応を受け入れられる新規／モダン設計
Aurora PostgreSQL / Serverless v2	既存PostgreSQLの全機能（PL/pgSQL・トリガー・外部キー・拡張）が必要、大きなトランザクション、単一リージョン中心、リフト＆シフト移行
DynamoDB	キー設計前提のNoSQL、超低レイテンシ、極端なスケール。SQL や結合が不要なアクセスパターン

逆に、数千行を超える一括更新のバッチ処理、PL/pgSQL・トリガー・外部キーに強く依存する既存資産、長時間接続前提の処理、全機能互換を期待するリフト＆シフト移行は不向きです。「ほぼ無限スケール」という表現に惹かれて要件を確かめずに選ぶと、制約とのミスマッチで苦労します。

まとめ

ポイントを3つに絞ります。

1. Aurora DSQL ＝ サーバーレスの分散SQL（PostgreSQL互換・マルチリージョン強整合・運用ゼロ）。ただし通常のAuroraとは別アーキの専用サービスで、単純な置き換えではありません。
2. 採用前に制約5点を必ず棚卸し：OCCリトライ／1トランザクション3,000行／DDL-DML分離／接続1時間／非対応機能（PL/pgSQL・トリガー・外部キー・一時テーブル）。
3. 料金はDPU＋ストレージ（アイドルでゼロ・参考値・公式要確認）。DPUは処理量課金で見積もりが直感的でない点に注意。他DBとは定性軸で使い分けを。記事①〜④と合わせ、モダンAWSバックエンドのデータ層ピースです。

Aurora DSQL を含む最近のAWSアップデートは AWS最新サービスの解説ハブ に横断的にまとめています。あわせてご覧ください。