Aurora DSQLとは：DPU課金・外部キー対応後の互換範囲とCLI接続手順、採用判断の基準

Amazon Aurora DSQL（以下DSQL）は、2024年12月3日にプレビューとして発表され、2025年5月27日に一般提供（GA）が開始されたサーバーレスの分散リレーショナルデータベースです。PostgreSQL 16互換をうたいながらトリガーやPL/pgSQLには対応せず、課金単位もインスタンス時間ではなくDPU（Distributed Processing Unit）へ置き換わっています。長く非対応だった外部キー制約は2026年8月26日に使えるようになりましたが、「PostgreSQL互換」という言葉から想像する移行の手軽さと、実際に必要な書き換え量には今も差があるのが実情です。この記事では、AWS公式ドキュメント・リリースノートとAWS Price List APIで確認した2026年10月時点の料金・上限値・非対応機能を整理し、CLIでクラスターを作ってpsqlで接続するまでの手順も示したうえで、どのワークロードなら採用でき、どこで想定外のコストと改修が発生するのかを判断できる材料をまとめます。

まとめ

• Aurora DSQLは2025年5月27日にGA。プレビュー期間は終了しており、2026年10月時点で東京・大阪を含む20リージョンで利用できます。
• 課金はDPUとストレージの2項目のみ。東京リージョンの単価は1 DPUあたり0.00001ドル（100万DPUで10ドル）、ストレージは0.40ドル／GB・月で、毎月10万DPUと1GBは無料枠です。
• PostgreSQL 16互換です。外部キーは2026年8月26日に対応しましたが、トリガー・PL/pgSQL・一時テーブル・TRUNCATEは引き続き使えません。トリガーやストアドの処理はアプリケーション層へ移す前提の設計です。
• 試すだけなら、CLIのaws dsql create-clusterでクラスターを作り、IAMトークンをパスワードにしてpsqlで接続するまで数分で済みます。手順は本文の「CLIでクラスターを作成」の章にまとめました。
• 1トランザクションで変更できるのは3,000行・10 MiB・5分まで。接続は60分でタイムアウトします。大量バッチ処理をそのまま持ち込む用途には向きません。
• ロックではなく楽観的同時実行制御（OCC）を使うため、コミット時のシリアライズエラーを前提としたリトライ実装が必須です。
• トランザクション単位の最小課金（読み取り2,048バイト相当、書き込み1,024バイト相当）があり、小さな書き込みを1件ずつ投げる設計はDPUを大きく浪費します。AWSの公式計算例（1行INSERT 0.06175 DPU／100行一括INSERT 0.70875 DPU）から計算すると、100行を1件ずつ挿入した場合のDPUは一括挿入の約8.7倍になります。

Aurora DSQLの提供状況と本番導入に関わるプレビュー版からの変更点

Aurora DSQLは、トランザクション処理向けに設計されたサーバーレスの分散リレーショナルデータベースです。アクティブ・アクティブ構成によって、単一リージョンで99.99%、マルチリージョンで99.999%の月間稼働率が正式なSLAとして定められています（2025年5月27日付。下回ると10%、99.0%を割ると25%、95.0%を割ると100%のサービスクレジット）。インスタンスサイズの指定もパッチ適用のためのメンテナンス時間もなく、コンピュート・I/O・ストレージが自動的にスケールします。

GA後に確定した本番利用の提供条件とリージョン拡大・追加機能の概要

GA時点の提供リージョンはバージニア北部・オハイオ・オレゴン・大阪・東京・アイルランド・ロンドン・パリの8つでしたが、2026年10月時点のAWS公式ユーザーガイドのリージョン一覧では20リージョンまで拡大しています（2026年2月にシドニー・メルボルン・カナダ2リージョン、5月に香港・ムンバイ・シンガポール・ストックホルム・サンパウロが加わるなど、段階的に追加）。プレビュー期間中に書かれた「利用可能なリージョンは限定的」「本番利用は不可」といった前提は、すでに当てはまりません。

GA後に追加された機能のうち実務上の影響が大きいのは次の2つです。1つは2025年11月に追加された、クエリプランへの文単位コスト見積り表示。もう1つは2026年7月8日に一般提供が始まった変更データキャプチャ（CDC）で、挿入・更新・削除の結果を変更イベントとしてAmazon Kinesis Data Streamsへ配信できます。CDCを有効にしたクラスターにはStream DPUが加算されます。

2026年8月から9月のリリースで変わった移行判断に関わる互換範囲

2026年8月から9月にかけて、移行判断に直結する変更が続きました。Aurora DSQLのリリースノートで確認できる主な項目は次のとおりです。

• 8月3日：ALTER TABLE ... DROP COLUMNと、既存データを検証せずにCHECK制約を足すADD CONSTRAINT ... NOT VALIDに対応
• 8月13日：式インデックス（例：lower(title)に張るインデックス）に対応
• 8月17日：文単位の負荷を待機イベント別に見られるDatabase Insightsに対応
• 8月24日から25日：SELECT FOR UPDATEの適用範囲拡大、SELECT FOR KEY SHARE、Drizzle ORM用アダプター
• 8月26日：外部キー制約に対応。text・varcharの大きな値の圧縮も開始
• 8月27日：CREATE STATISTICSによる拡張統計に対応
• 9月11日から15日：バッチ化したネステッドループ結合と、部分インデックス（WHERE句付きのCREATE INDEX）に対応

この結果、2026年前半までの解説記事にある「外部キーが使えないので参照整合性はすべてアプリで守る」という前提は崩れています。一方で、トリガー・PL/pgSQL・一時テーブル・TRUNCATEは2026年10月時点でも非対応のままです。DSQLの互換範囲は月単位で広がっているため、移行可否を判断する直前にリリースノートを読み直す運用を組み込んでください。

「DSQL」で検索して見つかる同名のPHPライブラリとAWS製品の区別

「dsql」という略称だけで検索すると、Agile Toolkit（atk4）が開発していたPHP用の動的SQLクエリビルダー「DSQL」の資料も混ざります。こちらはデータベースそのものではなくSQL文を組み立てるライブラリで、GitHubのatk4/dsqlリポジトリには「atk4/dataへ統合された」と明記され、単独のプロジェクトとしては更新が止まっています。本記事が扱うのはAWSのデータベースサービスであるAurora DSQLで、両者に技術的な関係はありません。

データベース層を支える4つの構成要素と独立したスケール・冗長化の仕組み

Aurora DSQLは、リレーおよび接続、コンピュートとデータベース群、トランザクションログ・並行性制御・分離、ストレージという4つのマルチテナントコンポーネントで構成され、コントロールプレーンがこれらを統括します。AWSはこの構造を「クエリ処理層・コミット層・ストレージ層がそれぞれ独立してスケールする」と説明しており、DPUがコンピュート・読み取り・書き込みに分かれて計測されるのもこの分離に対応した仕組みです。各コンポーネントは3つのアベイラビリティーゾーン（AZ）にまたがって冗長化されており、障害時は健全なインフラへ自動的にリクエストが振り向けられます。従来のAuroraのようにライターとリーダーを意識してフェイルオーバーを設計する作業自体が不要になる、という点が構造上の違いです。

CLIでクラスターを作成しpsqlで接続するまでの具体的な検証手順

料金や互換範囲を読む前に、実物を触っておくと以降の章が理解しやすくなります。AWS公式のGetting startedはコンソール操作で説明していますが、ここでは同じ流れをAWS CLIで再現します。2025年12月のアップデートでクラスター作成は数秒で終わるようになっており、作成から最初のSQLまでの待ち時間はほとんどありません。

CLIによる単一リージョンのクラスター作成とACTIVEまでの待機

create-clusterは、オプションを付けなければ単一リージョンのクラスターを作ります。削除保護は既定で有効なので、検証用で後から消す前提なら--no-deletion-protection-enabledを付けておくと片付けが楽です。戻り値のidentifier（英小文字と数字26桁）を控え、wait cluster-activeでACTIVEになるまで待ちます。このウェイターは2秒間隔で最大60回確認し、それでもACTIVEにならなければ終了コード255で抜けます。

# 東京リージョンに単一リージョンクラスターを作成（検証用なので削除保護は外す）
aws dsql create-cluster \
  --region ap-northeast-1 \
  --no-deletion-protection-enabled \
  --query identifier --output text

# 返ってきたIDを変数に入れ、ACTIVEになるまで待つ
CLUSTER_ID=foo0bar1baz2quux3quuxquux4
aws dsql wait cluster-active --region ap-northeast-1 --identifier "$CLUSTER_ID"

# 接続先ホスト名はエンドポイントとして取得できる
aws dsql get-cluster --region ap-northeast-1 --identifier "$CLUSTER_ID" \
  --query endpoint --output text

IAMトークンの発行からpsqlでのSSL接続と読み書き確認までの手順

DSQLはパスワード認証を持たず、IAMで署名したトークンをパスワードとして渡します。公式のpsql接続手順では、generate-db-connect-admin-auth-tokenの結果をPGPASSWORDへ入れ、PGSSLMODE=requireを指定して接続します。SSLなしの接続は拒否される仕様です。クライアントはpsql 14以上が条件で、応答時間の面ではPostgreSQL 17のクライアントが推奨されています。ユーザーはadmin、データベース名はpostgresで固定です。

HOST=$(aws dsql get-cluster --region ap-northeast-1 \
  --identifier "$CLUSTER_ID" --query endpoint --output text)

# 有効期限3600秒の管理者トークンをパスワードとして使う
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token \
  --region ap-northeast-1 \
  --expires-in 3600 \
  --hostname "$HOST")
export PGSSLMODE=require

psql --quiet --username admin --dbname postgres --host "$HOST"

接続できたら、公式手順と同じくUUIDを主キーにした表で書き込みと読み取りを確かめます。DDLとDMLは同じトランザクションに混在できないため、psqlの自動コミットのまま1文ずつ実行してください。

CREATE SCHEMA IF NOT EXISTS test;

CREATE TABLE IF NOT EXISTS test.hello_world (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  message VARCHAR(255) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO test.hello_world (message) VALUES ('Hello, DSQL');
SELECT * FROM test.hello_world;

-- 後片付け
DROP TABLE test.hello_world;
DROP SCHEMA test;

検証が終わったらaws dsql delete-cluster --region ap-northeast-1 --identifier "$CLUSTER_ID"でクラスターを削除します。アイドル中のDPUはほぼ発生しませんが、ストレージ料金は残るためです。アプリケーションから接続する場合は、トークン生成と接続プールを肩代わりするAWS公式のコネクター（Python・Node.js・JDBC・Go・.NET・Rust・Ruby・PHPなど）を使うと、既定で15分の有効期限を持つトークンの再発行を自前で書かずに済みます。

DPU課金の内訳と東京リージョンの実単価から見る費用見積りの前提

Aurora DSQLの請求書に並ぶ項目は、DPUとストレージの2つだけです。ただしDPUは内部的に複数の要素の合計であり、どの操作がどの要素を押し上げるのかを理解しないとコストを見積もれません。

DPUを構成する5つの要素と読み書き・CDC・リージョン別の計算式

単一リージョンのクラスターでは、1トランザクションのDPUはコンピュート・読み取り・書き込みの3要素の合計です。マルチリージョンではMultiRegion Write DPU、CDC有効時はStream DPUが加算されます。表のRはストレージからの読み取りバイト数、Wはストレージへの書き込みバイト数を表し、maxは括弧内の2つの値のうち大きいほうを採る関数です。

読み取りは「返した行」ではなく「スキャンした行」で課金されます。AWSの計算例では、100行をスキャンして条件で10行に絞り込むクエリは100行分のRead DPUを請求されます。丸めの対象は読み書きの双方です。書き込みは128バイト未満の行を128バイトとして計算し、読み取りは1ストレージパーティションあたりの応答が128バイト未満の場合に128バイトへ切り上げます。さらに書き込みトランザクションは、主キーの一意性確認のためにRead DPUも発生します。

東京リージョンの単価と無料枠による費用試算・オハイオとの料金比較

単価はリージョンごとに異なります。AWS Price List API（AuroraDSQLの版20260714190804）で確認した実値は次のとおりです。AWS公式の料金ページが見出しに掲げる「100万DPUあたり8ドル」はオハイオ（us-east-2）基準の数字であり、東京は25%高い点に注意してください。

AWSの公式計算例にある1行INSERT（0.06175 DPU）を東京の単価に当てはめると、100万回で0.62ドルです。同じく単一行の点検索（0.00675 DPU）なら100万回で0.07ドルにとどまります。小規模なサービスであれば毎月の無料枠10万DPUだけで、1行INSERT換算でおよそ162万回分をまかなえる計算です。アイドル時はDPU消費がスケールゼロし、時間単位の最低料金もないため、断続的にしかアクセスがないワークロードではプロビジョニング型より安くなります。ただし完全にゼロ円にはならず、ストレージ料金と、統計更新やコンパクションといったバックグラウンド処理の分は発生します。単価は改定されるため、最終的な金額はAWS公式の料金ページで確認してください。

小さな書き込みのコストを左右するトランザクション最小課金と一括処理

Aurora DSQLのコストで最初に効いてくるのは、行数でもデータ量でもなくトランザクションの粒度です。読み取りは合計2,048バイト未満でも2,048バイト分（0.00375 DPU）、書き込みは1,024バイト未満でも1,024バイト分（0.05 DPU）が課金されます。128バイトの行を1件挿入しても、行サイズの8倍にあたる1,024バイト分で請求されるということです。

AWSの公式計算例から計算すると差は明確です。100行を1件ずつ挿入すると0.06175 DPU × 100 = 6.175 DPU、同じ100行を1文の一括INSERTにまとめると0.70875 DPUで、約8.7倍の開きが出ます（コンピュート時間はAWSの例が置いた前提値なので、実際の比率は処理時間に依存します）。ORMのループで1行ずつ保存する実装や、レコード単位でトランザクションを切るバッチ処理をそのまま持ち込むと、この差がそのまま請求額に乗ります。移行前に、書き込みをまとめられる箇所を洗い出しておくべきです。

見積りにはEXPLAIN ANALYZE VERBOSEを使います。Aurora DSQLはこの出力の末尾に文単位のDPU見積りを追加します。VERBOSEを付けないEXPLAIN ANALYZEではDPU情報は出力されません。

EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;

Statement DPU Estimate:
  Compute: 0.01607 DPU
  Read: 0.04312 DPU
  Write: 0.00000 DPU
  Total: 0.05919 DPU

トランザクション最小課金が効く場合は、Read: 0.00307 DPU (Transaction minimum: 0.00375) のように括弧で最小値が併記されます。1文だけのトランザクションを見積もるときは、括弧内の値を採用してください。

ただしAWSはこの値を「請求グレードの指標ではない」と明示しています。文単位の見積りである一方、実際の課金はトランザクション単位の最小値が適用され、CloudWatchには非同期ANALYZEやコンパクションなどのバックグラウンド処理も含まれるためです。クエリ間の相対比較とチューニングに使い、確定値はCloudWatchのTotalDPUや請求レポートで確認する、という使い分けになります。

PostgreSQL互換の実際の範囲と既存アプリ移行時の書き換え箇所

Aurora DSQLはPostgreSQL 16をベースにしており、パーサー・プランナー・オプティマイザ・型システムといった中核部品と、標準のPostgreSQL v3ワイヤプロトコルを使います。psqlや既存のドライバー、主要なORMはそのまま接続可能です。ただし認証はパスワードではなくIAMで、aws dsql generate-db-connect-admin-auth-token（管理者以外はgenerate-db-connect-auth-token）で発行した期限付きトークンをパスワード欄に渡します。既定の有効期限は15分で、最長で604,800秒（1週間）まで設定できます。接続確立後はトークンが失効しても接続自体は有効なままなので、詰まるのは再認証のタイミング設計、つまり接続プールの側です。もう一方の移行工数の実体が、分散アーキテクチャを成立させるために落とされた機能です。プロビジョニング型のAurora PostgreSQLの対応バージョンと拡張機能と見比べると、DSQLが「PostgreSQLのどこまでを持ち込めるか」が具体的に見えてきます。

既存PostgreSQLスキーマで確認すべき非対応の機能と代替手段

外部キーは、公式の外部キー解説によるとNO ACTION・RESTRICT・CASCADE・SET NULL・SET DEFAULTの参照動作と、遅延可能（DEFERRABLE）な制約まで扱えます。ただし仕組みはPostgreSQLと違い、ロックを取りません。参照先の存在はトランザクション開始時点のスナップショットで確かめ、開始からコミットまでの間に参照先が消された場合は、コミット時の競合判定（暗黙のKEY SHARE）でシリアライズエラーにします。したがって外部キーを付けた表では、参照先の削除と参照元の挿入が並行すると後からコミットした側が40001で失敗し、後述のリトライ処理が前提になる点は変わりません。参照元・参照先へのDMLには整合性確認のための読み取りが加わり、その分Read DPUも増えます。既存表に後から付ける場合はALTER TABLE ... ADD CONSTRAINT ... NOT VALIDで追加します。大きな表でも書き込みを止めずに制約を足せる反面、既存行が制約を満たしているかは追加時点では検査されないため、移行前のデータに孤児行が残っていないかを別途SQLで確認しておくべきです。

CREATE TABLE products (
  product_id integer PRIMARY KEY,
  name text,
  price numeric
);
CREATE TABLE orders (
  order_id integer PRIMARY KEY,
  product_id integer REFERENCES products,
  quantity integer
);
-- 参照先の主キー以外の列を更新しても、参照元の挿入とは競合しない
-- 参照先の行を削除するトランザクションと並行した挿入は、コミット時にOC000で失敗する

シーケンスは「対応」ですが、既存スキーマをそのまま持ち込めるという意味ではありません。CREATE SEQUENCEはCACHEの明示指定を必須とし、受け付ける値はCACHE 1または65536以上に限られます。データ型もbigintのみです。サポートされるデータ型の一覧にserial・bigserialは含まれないため、連番の主キーをSERIALで定義している既存スキーマは、GENERATED AS IDENTITYか明示的なCREATE SEQUENCEへの書き換えが必要です。なおCACHEを65536以上にすると値の一意性は保たれますが、セッションをまたいだ厳密な昇順は保証されず、欠番も生じます。

jsonとjsonbも利用できます。1 MiBの上限は圧縮後のサイズに対して適用されるため、圧縮が効けば1 MiBを超える値も格納できます。ただしインデックスは張れないので、JSON内の属性で絞り込む設計は避けてください。「Aurora DSQLはJSON非対応」と書かれた解説は2026年前半までの情報です。

インデックス作成にも構文の変更が必要です。既存の行があるテーブルへインデックスを追加する場合は、CREATE INDEXではなくCREATE INDEX ASYNCを使います。このコマンドはロックを取らずジョブIDを即座に返すため、進捗はsys.jobsビューで確認し、完了を待つ必要があればsys.wait_for_job(job_id)で待機します。ビルドに失敗したインデックスは定義が残ったままINVALID状態になり、自動では削除されません。DROP INDEXで手動削除してから作り直す必要があります。データベースはUTF-8、照合順序はCのみ、システムタイムゾーンはUTC固定で、トランザクション分離レベルはRepeatable Readに固定されています。分離レベルをSerializableへ引き上げる、といった調整はできません。

楽観的同時実行制御を前提とした競合エラーの捕捉とリトライ実装の条件

Aurora DSQLはロックを取得せず、楽観的同時実行制御（OCC）でコミット時に競合を検出します。トランザクションがロック待ちでブロックされることがないためデッドロックは発生せず、遅いトランザクションが他をふさぐこともありません。その代わり、競合したトランザクションはシリアライズエラーで失敗します。

したがって、リトライ処理はオプションではなく前提条件です。捕捉すべきはSQLSTATE 40001で、内訳は2種類あります。同じ行を2つのトランザクションが更新しようとした場合のOC000（change conflicts with another transaction）と、セッションが保持するスキーマカタログのキャッシュが古くなった場合のOC001（schema has been updated by another transaction）です。後者はCREATE TABLEやALTER TABLEだけでなくGRANT・REVOKEでも発生するため、マイグレーション実行中にアプリ側が受け取る点に注意してください。トランザクションを冪等に設計し、これらを捕捉して再実行する仕組みを組み込む必要があります。AWSはあわせて、更新をキー空間に分散させるためにランダムな主キー（UUIDなど）を使うことを推奨しています。連番の主キーは書き込みが特定のパーティションに集中するため、OCC競合の発生源です。競合の実測はCloudWatchのOccConflictsメトリクスで追えます。

バッチ移行の可否を左右するトランザクションとクラスターの上限値一覧

移行可否を左右する数値上限は次のとおりです。とくに1トランザクション3,000行という制限は、既存のバッチ処理をそのまま持ち込めるかどうかの分かれ目になります。

加えて、DDLとDMLは同一トランザクションに混在できず、1トランザクションに含められるDDLは1文までです。マイグレーションツールが複数のDDLを1トランザクションにまとめて発行する構成になっている場合は、その前提から見直す必要があります。

マルチリージョンクラスターの構成とwitnessリージョンの配置制約

マルチリージョンクラスターは、2つのリージョンにピアリングされたクラスターと、3つ目のwitnessリージョンによる構成です。ピアリングされた2つはそれぞれリージョナルエンドポイントを持ち、両方が読み書き可能なまま単一の論理データベースとして振る舞い、強い整合性を保ちます。witnessリージョンはエンドポイントを持たず、暗号化されたトランザクションログを限られた期間だけ保持して、コミット時のクォーラム判定に加わります。片方のアクティブリージョンが停止しても、残るアクティブリージョンとwitnessで多数派が成立するため、トランザクションは止まりません。

作成手順はwitnessリージョンの指定から始まります。ピアになる2つのクラスターを同じwitnessリージョンを指定して作成し、そのうえで互いのARNを登録してピアリングを成立させます。

aws dsql create-cluster \
  --region ap-northeast-1 \
  --multi-region-properties '{"witnessRegion":"ap-northeast-2"}'

aws dsql create-cluster \
  --region ap-northeast-3 \
  --multi-region-properties '{"witnessRegion":"ap-northeast-2"}'

aws dsql update-cluster \
  --region ap-northeast-1 \
  --identifier 'foo0bar1baz2quux3quuxquux4' \
  --multi-region-properties '{"witnessRegion":"ap-northeast-2","clusters":["arn:aws:dsql:ap-northeast-3:111122223333:cluster/foo0bar1baz2quux3quuxquux5"]}'

同じupdate-clusterを大阪側にも実行して双方向にピアを登録すると、両クラスターがPENDING_SETUPからCREATINGを経てACTIVEになります。片側だけではセットアップは完了しません。

東京・大阪のマルチリージョン構成で日本国内に完結しないデータ配置

マルチリージョンクラスターを構成できる組み合わせはリージョンセット内に限られ、大陸をまたぐ構成はサポートされていません。2026年10月時点の公式一覧では、アジアパシフィックのセットは香港・ムンバイ・大阪・ソウル・シンガポール・東京の6つです。シドニーとメルボルンは単一リージョンクラスターのみで、このセットには含まれていません。

ここで日本国内のシステムにとって見落としやすいのが、データ配置の制約です。日本にあるリージョンは東京と大阪の2つだけなので、この2つでマルチリージョンクラスターを組むと、3つ目のwitnessリージョンは必然的に香港・ソウル・シンガポール・ムンバイのいずれか、つまり国外になります。witnessは完全なデータのコピーを保持しませんが、暗号化されたトランザクションログを一定期間保持します。「データを国内に閉じる」ことが要件になっている案件では、この点を単一リージョン構成を選ぶ理由として最初に検討すべきです。単一リージョン構成でも3つのAZにまたがる冗長性と99.99%の可用性設計は得られます。

マルチリージョンでは課金も増えます。ピアリージョンへの書き込みはMultiRegion Write DPUとして、元の書き込みDPUと同額が追加で発生します。8 DPUの書き込みトランザクションは、合計16 DPU相当になる計算です。ストレージ料金もリージョンごとに個別に課金されます。一方、witnessリージョンにはDPUもストレージも課金されません。

Aurora PostgreSQL・DynamoDBとの使い分け

Aurora DSQLが向くのは、リレーショナルなデータモデルとACIDトランザクションを必要としつつ、トラフィックの変動が大きく、運用の手離れを優先したいワークロードです。マイクロサービス、サーバーレス、イベント駆動型アーキテクチャのバックエンドが典型例になります。

逆に、次のいずれかに当てはまるなら現時点では見送りを推奨します。第一に、トリガー・PL/pgSQL・一時テーブルに依存した既存スキーマをそのまま載せ替えたい場合。外部キーは2026年8月に使えるようになりましたが、トリガーとストアドプロシージャの処理は互換性の看板とは裏腹に、アプリケーション層への書き換えが必ず発生します。第二に、数万行単位の一括更新を行うETLやバッチ処理。3,000行・10 MiB・5分の上限に阻まれ、分割設計が必須になります。第三に、集計や分析が主体のクエリ。返した行ではなくスキャンした行にRead DPUが課金されるため、フルスキャンを伴う分析用途はコスト効率が悪化します。第四に、データを国内に閉じたうえでマルチリージョン化したい場合です。

プロビジョニング型の性能特性やバージョン管理を握りたい、あるいはPostgreSQLの拡張機能を使いたいなら、従来のAmazon Auroraが引き続き適します。負荷変動への追随を重視しつつPostgreSQLの機能を落としたくない場合は、Amazon Aurora Serverless v2が中間の選択肢になります。キーバリューのアクセスパターンが中心で結合を必要としないなら、Amazon DynamoDBのキー設計と容量モードで組むほうが単純です。Aurora DSQLは、この3つのどれでもない「SQLとACIDは必要だが、インスタンス管理はしたくない」という領域を埋めるサービスです。AWSの外まで視野を広げると、TrueTimeで外部整合性を保つCloud Spannerや、PostgreSQL互換の分散SQLであるCockroachDBと同じ分散SQL（NewSQL）の系譜にあたり、Aurora DSQLはそこにPostgreSQL互換とDPU従量課金という組み合わせで加わった選択肢だと捉えると位置づけが整理できます。CockroachDBとはPostgreSQLのワイヤプロトコル互換を持ち、競合時にSQLSTATE 40001を返してクライアント側の再試行を求める点が近い一方、DSQLはクラスターのノード数を利用者が決めない完全サーバーレスで、自前運用やライセンス費用の選択肢がない点が異なります。

既存システムへの採用を決める前に確かめる互換性・処理量など5つの条件

判断を言い切るために、既存システムをDSQLへ載せるかどうかは次の5点で決めることを勧めます。5点すべてを満たすなら採用、1つでも満たせないなら、その項目を解消する改修費とAurora PostgreSQLを使い続ける運用費を比べて決めます。

1. トリガー・PL/pgSQL・一時テーブル・TRUNCATEを使っていない、またはアプリ側へ移す工数を見積もれている
2. 1トランザクションの変更が3,000行・10 MiB・5分に収まる、またはバッチを分割できる
3. 主キーをUUIDなどのランダム値にでき、OCCのリトライをアプリに組み込める
4. 処理の中心が点検索と小さな更新で、フルスキャンを伴う集計は別の分析基盤へ逃がせる
5. マルチリージョンにする場合、witnessの国外配置が契約上・規程上許される

逆に、5点の確認を省いて「PostgreSQL互換だから載せ替えられる」と進めると、移行の後半でトリガーの書き換えとバッチ分割が同時に発生し、工期が読めなくなります。既存スキーマの棚卸しとDPU見積りを含めた移行計画は、一創のデータベース設計・移行支援で、Aurora PostgreSQLを据え置く案との比較まで含めて支援しています。

バックアップからの復元時のクラスター切り替えと本番運用の監視項目

バックアップはAWS Backupとの統合で提供され、クラスター全体のバックアップ、スケジュールと保持ポリシーの自動化、クロスリージョンおよびクロスアカウントのコピー、Vault LockによるWORM（追記のみ）構成に対応します。運用設計で押さえておくべきなのは、復元の挙動です。AWS Backupはリストア時に必ず新しいクラスターを作成し、元のクラスターを上書きしません。既存クラスターを特定時点の状態に戻すという操作にはならないため、切り戻し手順はエンドポイントの切り替えを含めて設計する必要があります。マルチリージョンクラスターを復元する場合は、事前に対象となる全リージョンへ同一のバックアップコピーを用意しておくことが条件です。

監視面では、DPU系メトリクス（ReadDPU、WriteDPU、ComputeDPU、TotalDPU）に加えて、ClusterStorageSize、TotalTransactions、QueryTimeouts、OccConflictsがCloudWatchへ発行されます。OCC競合とクエリタイムアウトはアプリケーション設計の問題を映すため、DPUのアラームと合わせて最初に監視対象へ入れておくべき指標です。2026年7月30日からはコンソールで累積DPUを確認してリアルタイムのアラートを設定できるようになり、8月17日には文単位の負荷を待機イベント別に分解するDatabase Insightsにも対応しました。DPUが急増したときに「どのSQLが原因か」まで追えるようになったので、本番投入前にこの2つを有効にしておくと、最小課金に引っかかっている小さなトランザクションを早く見つけられます。

よくある質問

Aurora DSQLはいつからプレビューではなく本番利用できますか？

2025年5月27日に一般提供（GA）が開始され、プレビュー期間は終了しています。GA時点では8リージョンでしたが、2026年10月時点では東京と大阪を含む20リージョンで利用できます。なお「DSQL」という略称は、同名のPHP用クエリビルダーを指す場合もありますが、AWSでデータベースとして提供されているのはAurora DSQLです。

Aurora DSQLの料金はいくらですか？

課金対象はDPUとストレージの2つに限られます。東京リージョンでは1 DPUあたり0.00001ドル（100万DPUで10ドル）、ストレージは0.40ドル／GB・月です。オハイオリージョンはそれぞれ0.000008ドル、0.33ドル／GB・月と安価です。全リージョン共通で毎月10万DPUと1GB・月の無料枠があり、アイドル時はDPU消費がスケールゼロして時間単位の最低料金もかかりません。ただしストレージ料金とバックグラウンド処理分は発生します。

Aurora DSQLとAurora PostgreSQLの違いは何ですか？

Aurora PostgreSQLはインスタンス（またはACU）を割り当てるプロビジョニング型で、PostgreSQLの拡張機能や外部キー、トリガー、PL/pgSQLをそのまま使えます。Aurora DSQLはインスタンスの概念がないサーバーレスの分散型で、課金はDPU従量、代わりにトリガーやPL/pgSQLなど一部の機能に対応しません（外部キーは2026年8月26日に対応済み）。既存スキーマの移行のしやすさではAurora PostgreSQL、運用の手離れと自動スケールではAurora DSQLが優位です。

既存のPostgreSQLアプリケーションはそのまま動きますか？

接続レイヤーは標準のPostgreSQL v3ワイヤプロトコルなので、ドライバーや主要なORMはそのまま使えます。外部キー制約は2026年8月から使えますが、トリガー、PL/pgSQL、一時テーブル、TRUNCATEは非対応で、これらを使っていれば書き換えが必要です。認証もパスワードではなくIAMで発行する期限付きトークンに変わり、既定の有効期限は15分です。加えて、コミット時のシリアライズエラー（SQLSTATE 40001）を再試行するリトライ処理の実装が前提になります。

1トランザクションで扱えるデータ量に制限はありますか？

変更できるのは3,000行まで、変更データ量は10 MiBまで、実行時間は5分までです。いずれも引き上げできません。読み取りの行数自体に上限はありませんが、5分のトランザクションタイムアウトに収まる必要があります。

関連記事

• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説
• Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説
• Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提
• ScalarDB Clusterとは｜異種DB横断でACIDを実現する構造・ライセンス・Kubernetes導入を解説
• Aurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断を実装者目線で解説
• Amazon DynamoDBとは：機能の全体像からローカル起動・キー設計・容量モード選定まで
• Cloud Spannerとは？分散リレーショナルDBの仕組み・TrueTimeと採用判断を実装者目線で解説
• CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説