はじめに
 |
| Amazon Aurora DSQL（アイコンは Aurora と一緒） |
先日 AWS Blocks の検証をしていた際、バックエンドの DB として Aurora DSQL が使われていました。「Aurora」と名前が付いているので既存の Aurora の派生かと思いきや、ちょっと毛色が異なるサービスだったのでちょっと調べてみました。
本記事では、Aurora DSQL がどういうサービスで、既存の DynamoDB や Aurora 系のサービスと何が違うのかを整理してみます。
まずは結論から
- Aurora DSQL は DynamoDB と Aurora PostgreSQL の「間」を埋める新しい選択肢
- サーバーレス（Scale to Zero）+ PostgreSQL 互換 SQL + マルチリージョン Active-Active
- ただし PostgreSQL フル互換ではない。使えない機能がいろいろ
AWS の RDB 関連サービス
AWS には RDB（リレーショナルデータベース）系だけでも以下のようなサービスがあります。
| サービス | 概要 |
|---|---|
| RDS | MySQL/PostgreSQL 等のマネージド DB。インスタンスベース |
| Aurora | RDS の高性能版。独自ストレージで高可用性 |
| Aurora Serverless | Aurora の自動スケール版。ACU ベース課金 |
| Aurora DSQL | サーバーレス分散 SQL。マルチリージョン Active-Active |
加えて良く使われる選択肢として NoSQL の DynamoDB もあります。「どれを選べばいいの？」となるのは当然です。
Aurora DSQL は 2024年12月の re:Invent で発表され、2025年5月に GA（一般提供）になった比較的新しいサービスです。名前に「Aurora」が付いていますが、既存の Aurora とはだいぶ異なるプロダクトのようです。
Aurora DSQL とは？
一言で書くと完全サーバーレスなリレーショナルデータベースです。
分類としては分散 SQLと呼ばれるデータベースになり、以下のような特徴があります。
- 完全サーバーレス: インスタンスの選定・管理が不要。使った分だけ課金。アイドル時はゼロ課金
- 分散 SQL データベース: データが複数ノードに分散配置され、ワークロードに応じて自動スケール
- PostgreSQL 互換: SQL の文法やドライバが PostgreSQL と共通。ただし制約あり
- マルチリージョン: 複数リージョンで Active-Active に書き込み可能。99.999% の可用性 SLA
- プロビジョニング: DynamoDB と同様、2クリック・数分で利用開始
従来のサーバーレス DB と比較すると、DynamoDB は SQL が書けない。Aurora Serverless はマルチリージョンの Active-Active 書き込みが出来ない。DSQL はこの両方を兼ね備えたデータベースとなります。
他の Aurora サービスとの比較
「Aurora」と名前が付いていますが、他のサービスとはアーキテクチャが根本的に異なります。
| 観点 | Aurora PostgreSQL | Aurora Serverless v2 | Aurora DSQL |
|---|---|---|---|
| アーキテクチャ | 単一ライター + 共有ストレージ | 同左の自動スケール版 | 分散型（完全別設計） |
| スケーリング方法 | インスタンスサイズ変更 | ACU(Aurora Capacity Unit) 自動 | DPU(Distributed Processing Unit) ベース自動 |
| マルチリージョン | リードレプリカ（書き込みは1リージョン） | 同左 | Active-Active（全リージョン書き込み可） |
| PostgreSQL 互換 | フル互換 | フル互換 | 制約あり |
| 同時実行制御 | ロックベース（悲観的） | ロックベース（悲観的） | OCC（楽観的） |
| ゼロスケール可否 | × | ○ | ○ |
| プロビジョニング | 10分以上、設定多数 | 数分、ACU 範囲設定 | 1〜2分、設定ほぼなし |
| 課金 | インスタンス時間 + I/O + ストレージ | ACU 時間 + I/O + ストレージ | DPU + ストレージのみ |
OCC（楽観的同時実行制御）— DSQL の核心
Aurora DSQL を理解する上で最も重要な概念が OCC（Optimistic Concurrency Control） です。
通常、RDB を扱う時は悲観ロック前提でアプリを構築すると思います。その逆の考え方になります。
それぞれの動作を図に表すと次のようになります。
悲観ロック（悲観的排他制御）（従来のRDB）
先に流れたトランザクション処理がコミットされるまでロック待ちになるため、データの整合性を保証することができます。一方で、スロークエリが走った場合は対象のトランザクションがコミットされるまで他のトランザクションは待ち状態になります。また、デッドロックのリスクもあります。
楽観ロック（楽観的排他制御）（DSQL）
悲観ロックとの最大の違いはロックしないこと(ロックフリー)。コミット時に競合が検出されなければOKという考え方です。このため、デッドロックが発生しなかったり、スロークエリが走った際も他のトランザクション処理は待たされずにコミットが可能であったり、というメリットがあります。その一方で、競合時に SQLSTATE 40001 エラーが返るので、アプリ側でリトライロジックを実装する必要があります。つまり、同じ行を頻繁に更新するようなアプリケーションでの利用には不向きと言えます。
楽観ロックでのスロークエリのトランザクション処理
スロークエリが走っている間に他のトランザクション処理が走ると、それらのコミットは成功します。その後、スロークエリのコミットが走ったタイミングで、競合エラーが発生しロールバックとなります。その後、アプリ側の実装により、スロークエリのリトライ処理が流れます。
OCC のリトライ設計は DSQL を使う上での最重要ポイントです。AWS Blocks を使う場合は { retryOnConflict: true } オプションで自動リトライが組み込まれるため、この部分の負担は軽減されます。
PostgreSQL との互換性
DSQL は PostgreSQL v3 ワイヤプロトコルを使うことができるため、psql や通常のドライバ（JDBC、psycopg、node-postgres）で接続できます。ただし フル互換ではありません。
使えるもの
| カテゴリ | 内容 |
|---|---|
| 標準 SQL | SELECT, INSERT, UPDATE, DELETE, JOIN, GROUP BY, HAVING, サブクエリ |
| 制約 | UNIQUE, CHECK, NOT NULL |
| ビュー | GA で対応済み |
| シーケンス | 2026年2月に対応（GENERATED ALWAYS AS IDENTITY、nextval()） |
| JSON | 2026年5月に対応（圧縮付き） |
| トランザクション | ACID 準拠（Snapshot Isolation） |
使えないもの
| カテゴリ | 代替手段 |
|---|---|
| FOREIGN KEY | アプリ層で実装 |
| トリガー | アプリ層 or CDC（2026年7月に対応） |
| ストアドプロシージャ | アプリ層で実装 |
| CREATE INDEX（同期） |
CREATE INDEX ASYNC を使用 |
インデックスのソート順指定（ DESC / ASC ） |
指定なしで作成 |
| 拡張機能（PostGIS 等） | 利用不可 |
ストアドプロシージャが使えないのは結構キツイですね。
インデックス関係は ASYNC を使って非同期にすることで使えます。前回の Blocks 検証記事でハマったポイントです。
トランザクションの制限
- DDL と DML は別トランザクション
- 1トランザクションに DDL は1文のみ
- 1トランザクションで変更可能な行数は最大 3,000行
変更可能な行数の制約があるのもツライですね。3,000行だと普通に使っていても制限に引っ掛かってしまいそう。
DSQL は「既存 PostgreSQL アプリの移行先」ではなく、「PostgreSQL の文法で新しく書く分散 DB」 と捉えるのが正確です。FK やトリガーをサポートしないのは「未実装」ではなく、分散アーキテクチャ上の設計判断です。PostgreSQL の SQL 文法やドライバ互換は維持しつつ、ストレージエンジンとトランザクション管理は完全に独自設計に置き換えているため、ストレージエンジンに深く依存する機能（FK、トリガー、ストアドプロシージャ等）は構造的に提供できません。これが OCC（ロックフリー）を実現できている理由でもあります。
実際に触ってみた
クラスター作成（コンソール）
DSQL のプロビジョニングがどれだけ手軽か、実際にコンソールから試してみました。
サービスを検索すると、Aurora & RDS とは別のメニューになっていることがわかります。
DSQL コンソールはこんな感じ。スッキリとしたメニュー構成です。
クラスターを作成するから始めます。シングル or マルチリージョンを選びます。
設定項目はほぼありません。従来の Aurora だとインスタンスクラス、ストレージタイプ、VPC、サブネットグループ、パラメータグループ…と選択肢が多いですが、DSQL ではクラスター名くらいです。
１分も待たずにクラスターが作成されました。
Query Editor
クラスターが作成できたら、そのままコンソールの クエリエディタ から SQL を実行できます。Data API の有効化やネットワーク設定は不要。VPC の中に入る必要もありません。
クラスターに接続を選ぶと、対象クラスターとロールを選ぶだけで接続できます。
初期の構成はこんな感じ。分かりやすく階層的に確認できます。
テーブルを作ってデータを入れてみます。
-- テーブル作成
CREATE TABLE products (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
name TEXT NOT NULL,
price NUMERIC(10,2) NOT NULL,
stock INT DEFAULT 0
);
まずはテーブル生成。結果も見やすいです。
エクスプローラー上にも細かく表示されます。
データ投入して、簡単なSQLを実行してみます。
-- データ投入
INSERT INTO products (name, price, stock) VALUES
('Widget A', 1200.00, 50),
('Widget B', 3400.00, 20),
('Widget C', 800.00, 100);
-- 集計クエリ
SELECT name, price, stock, price * stock AS inventory_value
FROM products
ORDER BY inventory_value DESC;
普通に SQL が動きます。PostgreSQL を触ったことがある方なら違和感なく使えるはずです。
「使えない機能」も試してみる
せっかくなので、DSQL で使えないとされている FOREIGN KEY も試してみました。
CREATE TABLE order_items (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
product_id UUID REFERENCES products(id), -- FK を指定
quantity INT NOT NULL
);
想定通りエラーになります。制約として把握しておけば、設計段階で回避できます。
DSQL Playground（AWS アカウント不要）
2026年2月から、AWS アカウントがなくても DSQL を試せる DSQL Playground が提供されています。ブラウザで Aurora DSQL Playground にアクセスするだけで、スキーマ作成・データ投入・SQL クエリ実行が体験できます。
クラスター作成も不要で、開いた瞬間から SQL が叩けます。上記の Query Editor で試した SQL もそのまま動くので、「まず雰囲気だけ見たい」場合はこちらのほうがお手軽です。
テーブル作成とデータ投入はそれぞれ決まったフィールドに投入します。
結果の確認はこのような形になります。
Playground は一時的なサンドボックス環境のため、作成したテーブルやデータはセッション終了後に消えます。永続化したい場合は自分の AWS アカウントでクラスターを作成してください。
後片付け
検証が終わったらクラスターを削除します。削除もコンソールから数クリックです。Scale to Zero なのでアイドル時は課金されませんが、ストレージ分は残るため不要なら削除しておきます。
クラスターの削除はちょっと時間かかります。。
コストについて
ワークロードに関わるコストは算出方法の違いから一概に比較できませんが、Aurora Serverless より一般的には高くなるようです。ストレージは明確に約50%高くなります。DSQL の 0.33ドル/GB に対して Serverless は 0.225ドル/GB。
ただし DSQL には毎月の無料枠（10万DPU + 1GBストレージ） があります。開発・検証環境で 1GB を超えることは稀なので、小規模な利用であれば実質無料で使えます。Aurora Serverless にはこの水準の無料枠がないため、「FK等の非互換機能が許容でき、開発環境やスモールスタートのアプリを置きたい」場合は DSQL のほうがコストメリットがあるケースもあります。
2026年のアップデート
DSQL は 2025年5月の GA 以降も機能追加が続いています。2026年の主なアップデートはこちら。
- シーケンス / IDENTITY（2月）
→ DB 側で連番 ID が生成できるように - JSON データ型サポート（5月）
→ JSON 形式でデータを取り扱うことが可能に - CDC — Change Data Capture（7月）
→ DSQL への各操作をリアルタイムで Kinesis Data Streams に配信 - リージョン拡大（5月）
→ 東京を含む19リージョンに展開済み - コネクタの充実
→ Go、Ruby、Python 等の各種言語向けコネクタが提供
CDC は 2026年7月8日に GA になったばかりの機能です。DSQL にはトリガーがないため、CDC + Lambda の組み合わせが事実上のトリガー代替になります。イベント駆動アーキテクチャとの相性が良く、サーバーレス構成で威力を発揮しそうです。
まとめ
今回は Aurora DSQL について調べてみました。
久しぶりにデータベースの技術的な面についてアレコレ深堀りできて、非常に勉強になりました。
実際に触ってみて、確かに「DynamoDB のようなお手軽さで RDB を使って SQL を書ける」感覚を掴むことができました。PostgreSQL と完全互換ではない点、注意すべきではありますが、使いどころがハマれば活躍しそうなサービスであるように思います。
ちょうどタイムリーに Aurora DSQL の活用についてエブリー社の事例が紹介されていました。
本記事中にもあるとおり、マルチリージョンが不要な単一リージョン構成であっても「新規サービス × スモールスタート × メンテナンスフリー」の組み合わせで DSQL を選択する実例が出始めています。
コスト面でも同社の試算では Aurora PostgreSQL（Provisioned）との比較で90%以上削減、Aurora Serverless v2 との比較でも大幅に安価になると見込んでおり、コスト面と運用負荷の両面で Aurora DSQL が新規サーバーレスアプリの有力な選択肢になる可能性がありそうです。
今後のアップデートにも注目しつつ、活用できそうな場面があれば積極的に使ってみたいと思います。