SQL互換性と実行可能性
35項目のSQL検査のうち、DSQLは17項目が通過し、16項目が未対応（0A000）でした。対照群3種はDSQL専用のCREATE INDEX ASYNCを除く34項目が通過しました。注文トランザクション（FKを含む）はDSQLで修正なしに通過しました。
測定日 2026-09-24実験の進捗
- 計画
- 0
- 進行中
- 0
- 完了
- 12
公開結果
測定・レビューを終えた記録OLTPスループットとレイテンシの限界
DSQL単独の再測定（2026-09-29）で、DSQLは接続256個の固定同時実行数で24,541 TPSを処理し、SLO（書き込みp99 35.7 ms）を守りました。同じ条件で対照群がSLOを守った最高スループットは、RDS Multi-AZが5,839、Aurora Provisionedが3,375、Aurora Serverless v2が11,559 TPSでした。DSQLのレイテンシは負荷にほぼ依存しませんでしたが、絶対値は書き込みp95約28–41 msで、Serverless v2（7–9 ms）より長くなりました。負荷発生器が飽和に近かったためDSQLの値は下限であり、本測定・反復は行っていません。
測定日 2026-09-29接続数、接続の急増、プーリング
MVP（DSQL単独）。IAMトークンの署名はp50 0.2 msで負担は小さく、新しい接続（TLS・認証・最初の照会）は逐次実行でp50 15.5 ms、p99 120 msでした。接続500個と1,000個を一度に要求しても、拒否なくすべて成功しました。一方、リクエストごとに新しい接続を張ると、16個のワーカーによる照会スループットは121 TPSとなり、接続を維持した場合（8,370 TPS）の約1/70でした。接続プールの利用は事実上必須であり、対照群との比較とRDS Proxyは測定していません。
測定日 2026-09-29トランザクションの競合とデータ整合性
66個の負荷セルと分離レベルのシナリオすべてで、業務不変条件の違反は0件でした。集中（hot）競合では、DSQLは待機せずにコミット時点の競合（40001）で失敗し、p99を110ms以下に保ちましたが、生の競合率は同時実行数256で67–71%まで上がりました。対照群（小型構成）はロック待機が2秒の期限を超え、スループットが数十TPSまで落ちました。反復1回・25秒のセル・小型の対照群による結果であり、容量比較の根拠ではありません。
測定日 2026-09-26読み取りのスケールと最新データの可視性
MVP。コミット確認の直後に別の接続から同じ行を読む試験200回で、DSQLは最初の読み取りから200回すべて新しい値を返しました(見えるまで p99 5.5 ms)。Aurora Serverless v2 の reader エンドポイントは200回中199回が最初の読み取りで古い値を返し、新しい値が見えるまで p50 21.8 ms、p99 32.6 ms かかりました。writer エンドポイントの別接続ではすぐに見えました。読み取りスループットのスケールは測定していません。
測定日 2026-09-29接続障害・サービスごとの復旧と成功したコミットの保持
MVP。毎秒300件の注文負荷の最中に、負荷発生器から DB へ向かうパケットを30秒間破棄するクライアント側のネットワーク障害を発生させました。DSQL と Aurora Serverless v2 のどちらも遮断区間のリクエストが接続エラーで失敗し、セル全体の失敗率は約20.6%でしたが、遮断解除後 0.02–0.07秒で新しい接続が成功し、業務レシートで突き合わせたコミットの消失・重複効果は両サービスとも0件でした。DB 側のフェイルオーバーと DSQL 内部の障害は試験していません。
測定日 2026-09-29バックアップ、ポイントインタイム復元、ミスからの復旧
MVP。約 100 MB のデータに秒単位のマーカー30個を書いた後、すべてのマーカーを上書きするミスを起こして復旧しました。DSQL はポイントインタイム復元がないため、ミスの前に取得した AWS Backup のフルバックアップ(481秒)から新しいクラスターに復元し、復元は129秒でした。Aurora Serverless v2 はミス直前の時刻へポイントインタイム復元し、クラスターの準備に223秒、インスタンスまで587秒でした。両方の復元先で正常なマーカー30個がそのまま残り、上書きされた行とミス後の行は0行でした。
測定日 2026-09-29データ増加と運用作業の影響
MVP(DSQL 単独)。毎秒1,000件の注文負荷の最中に、注文1,100万行に非同期インデックスを作成しました。コマンドは0.1秒で戻り、インデックスが実際に使える状態になるまで736秒かかりました。ビルド中に注文作成の p95 は 27.5 ms から 52.0 ms に、p99 は 30.7 ms から 79.8 ms に増えましたが SLO 内で、失敗は0件でした。列の追加・削除とインデックスの削除は0.1秒以内に終わりました。5,000行を変更するトランザクションと310秒間開いたままのトランザクションは、それぞれ行数の上限と300秒の上限で拒否されました。
測定日 2026-09-29DSQLと既存サービスの負荷急増への対応とアイドル後の再開
MVP。毎秒200→2,000→1,000→50件と変化する急増負荷で、DSQLとAurora Serverless v2はいずれも手動介入なしで失敗0件で処理した。DSQLの書き込みp95は負荷に関係なく29–36 msで一定で、A2は8–12 msだった。15分間まったく接続がなかった後の最初のリクエストでは、DSQLは接続112–287 ms、最初の照会115–123 msで応答したが、0 ACUまで自動一時停止したA2は再開が遅く、最初の接続が2回とも15秒のタイムアウトを超えて失敗した。
測定日 2026-09-29同じ業務の費用と選択基準
MVP（追加のAWS実行なし）。E002・E009の測定値から、同じ注文業務の時間あたり費用を計算した。DSQLはリクエスト数に比例してリクエスト100万件あたり約USD 0.31（リクエストあたり0.029–0.032 DPU）かかり、RDS Multi-AZは負荷に関係なく時間あたり約USD 1.22だった。平均負荷が約1,100 TPSより低いかアイドル時間が長ければDSQLが安く、それより高い負荷が続けば固定インスタンスが安い。リードレプリカを置いたAurora Serverless v2は、測定したすべての負荷でDSQLより高いか同程度だった。
測定日 2026-09-29DSQLの開発・運用のしやすさと導入負担
MVP（追加のAWS実行なし）。E001–E012で4つのサービスを実際に作成・使用・削除する中で経験した作業をまとめた。DSQLは作成32秒・削除約2分で、Aurora Serverless v2（作成約11分、削除約15分）より速く、容量の選択・パスワード管理・vacuum・readerルーティングが不要だった。一方、業務SQL 35個のうち16個を修正する必要があり、競合時のリトライ、3,000行・300秒でのトランザクション分割、非同期インデックスの完了確認、外部キー側インデックスの手動作成、1時間ごとの接続入れ替え、IAMトークン署名、ポイントインタイム復元がないことへの対応のためのコードと手順が追加で必要だった。作業時間は測定していない。
測定日 2026-09-29DSQLの大規模な照会・集計とOLTPへの干渉
MVP（DSQL単独、Sデータ）。顧客ごとの最近の注文のJOINはp50 4.4 msで、注文の10%（110万行）の日別売上集計は2.4–2.6秒、注文品目約27万行の商品ランキングは0.7秒、注文1,100万行全体の集計は約36秒だった。全体集計1回に約1,700 DPU（約USD 0.017）かかった。毎秒1,000件の注文負荷の中で10%集計を休みなく繰り返しても、OLTPは失敗0件でSLOを守り、注文作成p99は30.7 msから41.8 msに増えた。対照群との比較とL規模のデータは測定していない。
測定日 2026-09-29実験一覧
計画の全文を読むOLTP、急増・アイドル、大規模な集計の順に進めます。使いやすさと費用は最初の作成から削除まで記録します。実験番号は実行順ではなく識別子です。
SQL互換性と実行可能性
DSQLで同じ業務を実装するには何を変える必要があるか？
結果 DSQLは17/35が無修正で通過、16項目が未対応（0A000）。対照群3種は34/35が通過
要約と本番利用の観点を見る
この実験では、既存のPostgreSQL業務をAurora DSQLへ移す際に、SQLをどの程度修正する必要があるかを確認しました。業務SQL 35項目を、DSQL（D1）と対照群の3サービス（RDS PostgreSQL、Aurora Provisioned、Aurora Serverless v2）でそのまま実行しました。DSQLは17項目を修正なしで通過し、16項目を「サポートされていない機能」（SQLSTATE 0A000）として拒否しました。対照群の3サービスは、DSQL専用構文であるCREATE INDEX ASYNCを除く34項目をすべて通過しました。
DSQLで修正が必要だった領域は、sequence・identityの宣言、serial型、インデックスの作成方法、一時テーブルとパーティション、PL/pgSQL関数とトリガー、分離レベルの指定、statement_timeout、サーバー側での文のキャンセルです。一方、PK・UNIQUE・CHECK・外部キーなどの制約、JOIN・CTE・window関数、JSONB、そして中核業務である注文トランザクションは元のまま動作しました。SELECT FOR UPDATEは構文としては通りましたが、動作が異なりました。対照群は他の書き込みを待機させましたが、DSQLは待機させず、コミット時点の競合（40001）で一方を失敗させました。したがって、DSQLへ移行するアプリケーションには、失敗したトランザクションを再試行するロジックが必要です。
この結果は、小型構成とローカルクライアントでSQL機能のみを検査したもので、各構成を1回ずつ実行しました。性能、レイテンシ、高可用性は評価しておらず、DSQLのサポート範囲は変わり続けるため、2026-09-24時点での観測として読む必要があります。
本番利用の観点
DSQLは制約・外部キー・JOIN・JSONBや注文トランザクションといった中核的なOLTP SQLを修正なしで実行したため、最初からDSQLの制約に合わせて設計する新規サービスであれば、SQL面での導入障壁は低いです。一方、既存のPostgreSQLサービスを移すには、sequence・serialの宣言、インデックスの作成方法、PL/pgSQL・トリガー、一時テーブル・パーティションを変更する必要があります。また、分離レベルはREPEATABLE READのみで、statement_timeoutとサーバー側のキャンセルが動作しないため、競合時の再試行とリクエストの期限をアプリケーションで実装する必要があります。ストアドプロシージャとトリガーにロジックが多いシステムほど、移行コストは大きくなります。この実験は機能検査にすぎず、性能・可用性はE002以降の実験で判断します。
完了P0Issue #1
OLTPスループットとレイテンシの限界
DSQLのSLO容量・レイテンシは各対照群の何倍か？
結果 接続256基準のSLO通過最高スループット：DSQL 24,541 TPS以上（下限）、A2 11,559、R1 5,839、A1 3,375 TPS。DSQL書き込みp95約28–41 ms、A2約7–9 ms
要約と本番利用の観点を見る
この実験では、同じ注文業務を同じレイテンシ目標（SLO）で実行したときに、DSQLが対照群よりどれだけ多くのリクエストを処理し、レイテンシがどう異なるかを確認しました。業務は商品照会40%、注文履歴照会30%、注文作成20%、注文キャンセル10%の混合で、SLOは読み取りp95 50 ms・p99 100 ms、書き込みp95 100 ms・p99 200 ms、技術的失敗率0.1%以下です。実験は2回に分けて実行しました。2026-09-28には4サービスを同時に起動してパイロットと同時実行数の探索を行いましたが、DSQLの探索が初期化の遅さと予算の制約で止まったため、2026-09-29にDSQLだけを新たに起動し、セルごとにデータを削除しない方式で再測定しました。
接続数を固定して休みなくリクエストを送る方式（closed-loop）で、DSQLは接続64個で6,680 TPS、接続256個で24,541 TPSを処理し、いずれもSLOを守りました。接続256個でも注文作成のp99は35.7 msで、接続64個（30.4 ms）とほぼ同じでした。同じ方式による対照群の測定（2026-09-28）では、接続256個で3つの対照群すべての書き込みレイテンシがSLOを超え、SLOを守った最高スループットはRDS Multi-AZ（R1）5,839 TPS、Aurora Provisioned（A1）3,375 TPS、Aurora Serverless v2（A2）11,559 TPSでした。接続256個の条件で、DSQLはA2の約2.1倍、R1の約4.2倍、A1の約7.3倍を処理しました。このとき負荷発生器のCPUは80.8%で飽和基準（85%）に近かったため、DSQLの値はサービスの限界ではなく、今回の測定の下限です。
レイテンシの絶対値はDSQLの方が長くなりました。同じ1,600 TPSで、DSQLの注文作成p95は41.0 ms（2026-09-28）、A2は6.8 msで、2026-09-29の測定ではDSQLの書き込みp95は約28–30 msでした。リクエストを決められた到着率で送る方式（open-loop）では、DSQLは6,750 TPSまでSLOを守り、8,100 TPSでp99が200 msを超えました。ただしこの失敗はDSQLの処理レイテンシ（p95約28 msで変化なし）ではなく、負荷発生器がプロセスごとに分けて使う接続を待った時間（待機p99約190 ms）によるものであるため、open-loopの限界は測定ツールの接続プールの限界と解釈します。すべてのセルで業務不変条件の違反は0件でした。計画していた共通到着率での本測定と反復はできなかったため、サービス間の差は1回の測定値です。
本番利用の観点
スループットの面では、DSQLは今回の実験で最も大きくスケールしました。接続256個で毎秒2万4千件以上の注文混合業務をレイテンシの増加なしに処理し、同じ条件で既存サービスはすべてレイテンシ目標を超えました。容量計画なしに負荷が増えても耐えられる点は、トラフィックの変動が大きいサービスに有利です。その代わり、リクエスト1件のレイテンシはAuroraより3–6倍長く（書き込みp95約30–40 ms）、リクエストごとに複数のクエリを順に実行する画面では応答時間が延びます。同じスループットを出すには接続と同時実行数をより多く使う必要があり、高いスループットを維持し続けるとDPU料金が大きくなります（E010）。
完了P0Issue #2
接続数、接続の急増、プーリング
DSQLの認証・接続の更新・急増への対応にはどのような負担があるか？
結果 MVP：新規接続p50 15.5 ms、同時接続1,000個で拒否0件。リクエストごとの新規接続時121 TPS vs 接続維持8,370 TPS（約1/70）
要約と本番利用の観点を見る
この実験では、アプリケーションがDSQLに接続する際にIAM認証と接続の確立がどの程度の負担になるか、また接続が一度に集中したときに拒否や遅延が起きるかを確認しました。最小範囲（MVP）として、E002規模のデータが入ったDSQLクラスター1つに対し、負荷発生器1台から、トークン署名、逐次接続、接続維持とリクエストごとの新規接続の比較、接続500個・1,000個の同時要求を測定しました。対照群は今回測定していません。
DSQLはパスワードの代わりにIAMで署名したトークンで認証します。トークンの署名はネットワーク呼び出しなしにランナー内で行われ、p50 0.2 msでした。最初の呼び出しだけはクライアントの初期化により131 msかかりました。新しい接続を張って最初の照会を終えるまでは、逐次実行100回でp50 15.5 ms、p95 109 ms、p99 120 msでした。
接続を維持した16個のワーカーは商品照会を毎秒8,370件（p50 1.9 ms）処理しましたが、リクエストごとに新しい接続を張ると毎秒121件（p50 131 ms）となり、約70分の1になりました。接続500個と1,000個を一度に要求したときは、すべて拒否なく成功しましたが、すべて確立されるまでにそれぞれ3.7秒と8.2秒かかりました。この速度（毎秒約120–135個）はリクエストごとに新規接続を張る場合のスループットと近く、DSQLの接続確立速度の制限なのか、ランナーの単一PythonプロセスがTLS接続を処理する限界なのかは、今回の測定では区別できませんでした。急増直後の新規接続はp50 16.2 msで、平常時と同じでした。
本番利用の観点
DSQLのIAMトークン認証自体の負担は小さいものでした。署名は0.2 msで、トークンを数分間再利用すれば接続ごとに署名する必要もありません。接続1,000個を一度に要求しても拒否されませんでした。しかし新規接続1回に15–120 msかかるため、リクエストごとに接続を新しく張る構造（例：接続プールなしで動作する短時間の関数）では、スループットが接続を維持した場合の約1/70に落ちました。接続プールを使い、DSQLは1時間を過ぎた接続を切断するため、プールが接続を定期的に入れ替えるように設定する必要があります。対照群とRDS Proxyとの比較は行っていません。
完了P0Issue #3
トランザクションの競合とデータ整合性
DSQLの競合・再試行は整合性・レイテンシ・実装量にどのような影響を与えるか？
結果 不変条件違反0/66セル。集中競合でDSQLは待機なしに40001で失敗（同時実行数256で競合率67–71%、成功リクエストのp99は110 ms以下）、小型の対照群はロック待機でスループットが急減
要約と本番利用の観点を見る
この実験では、同じ行を複数のリクエストが同時に更新するときにDSQLと対照群が整合性を守るか、また競合と再試行がレイテンシと失敗率にどのような影響を与えるかを確認しました。注文作成と口座振替の業務を、同時実行数16/64/256、均等アクセスと人気キーへの集中アクセスに分けて実行し、負荷セルごとに在庫・残高・重複処理の不変条件を検査しました。66個の負荷セルすべてで不変条件の違反は0件でした。4サービスとも、条件付き更新、業務IDのレシート、再試行、コミット有無の確認を実装すれば、二重処理やコミットの消失なしに動作しました。
競合の扱い方は大きく異なりました。DSQLはロック待機なしに、コミット時点で競合（40001）を通知します。そのため、上位1%のキーにリクエストの80%が集中する集中競合では、コミットに成功したリクエストのp99は110 ms以下と短かったものの、同時実行数256の競合率は67–71%で、最大3回の再試行後も39%が最終的に失敗しました。対照群は行ロックでリクエストを順番待ちさせ、同時実行数64と256の集中競合では待機が2秒の期限を超えて、成功スループットが24–512 TPSに落ち、最終失敗率が18–63%になりました。DSQLはREAD COMMITTEDをサポートしないため再試行の実装は必須であり、人気商品のように競合が集中する業務では、再試行の予算と競合を分散するスキーマ設計を併せて検討する必要があります。
費用上限（当時USD 5、後に50へ引き上げ）のため対照群をバースト可能な小型インスタンスに縮小し、セルは25秒ずつ1回だけ実行しました。したがってスループットの差はサービス比較の根拠には使わず、固定同時実行数の方式であるため、リクエストが滞留している間のレイテンシが漏れる可能性があります。計画規模での容量とレイテンシの比較は、E002でリクエスト率を固定する方式で再測定します。使用量から計算した推定費用は約USD 3.4で、Cost Explorerで確認した実際の請求額は約USD 2.07です（主な差はDSQLの月間無料使用量の差し引き）。
本番利用の観点
再試行と業務IDのレシート（冪等処理）を実装すれば、DSQLも競合状況で二重処理やコミットの消失なしに整合性を守ったため、整合性自体は本番導入の障害ではありませんでした。競合が分散した業務では競合率は既存サービスと同程度で、再試行でほとんど解消されました。しかし人気商品の在庫のように少数の行に書き込みが集中すると、再試行後も失敗が大きく残るため（同時実行数256で39%）、こうした業務は在庫行の分割のようなスキーマの再設計なしにはそのまま移すのが困難です。トランザクションあたり3,000行の制限のため大量削除・整理作業を分割する必要があり、サーバーエラーも1回観測されたため、再試行は必須です。小型の対照群・反復1回の結果であるため、容量の判断はE002で行います。
完了P0Issue #4
読み取りのスケールと最新データの可視性
DSQLは reader への分散と比べて、性能・最新性・ルーティング作業がどう異なるか?
結果 MVP: 書き込み直後の別接続の読み取りで DSQL の古い値 0/200、A2 reader の古い値 199/200(見えるまで p99 32.6 ms)
要約と本番利用の観点を見る
この実験では、書き込みがコミットされた直後に別の接続からその値をすぐ読めるかどうか、つまり最新データの可視性を DSQL と Aurora Serverless v2(A2)で比較しました。計画の全範囲ではなく最小範囲(MVP)に絞り、ある接続で行を挿入してコミット応答を受け取った直後から、別の接続が 10 ms 間隔でその行を照会する試験を200回繰り返しました。
DSQL(D1)では、200回すべてで最初の照会から新しい行が見えました。2つ目の接続が行を確認するまでの時間は p50 2.1 ms、p99 5.5 ms で、照会1回の往復時間程度でした。DSQL は接続先が1つだけで、コミット済みのデータはどの接続からもすぐに読めたため、アプリケーションが書き込み直後の読み取りを writer に送るルーティング規則を別途用意する必要はありませんでした。
A2 では、writer エンドポイントの別接続からは200回すべてですぐに見えましたが(p99 0.5 ms)、reader エンドポイントで照会すると200回中199回が最初の照会で行を見つけられませんでした。新しい行が reader で見えるまで p50 21.8 ms、p95 22.1 ms、p99 32.6 ms、最大 65.5 ms かかりました。reader に読み取りを分散する構成では、「書き込み直後に自分の書き込みを読む」必要があるリクエストを writer に送るか、数十 ms の遅延を許容する必要があります。今回は読み取りスループットのスケールや reader 数に応じた性能は測定していません。
本番利用の観点
最新性の面では DSQL が有利でした。コミット直後の別接続でも200回すべて新しい値を読めたため、従来の Aurora のように reader の複製遅延(今回の測定で p99 約 33 ms)を避けるために書き込み直後の読み取りを writer に送るルーティングコードは不要です。注文直後に注文内容を表示する画面のように、自分の書き込みをすぐ読む必要がある業務では実装が単純になります。ただし、読み取りスループットをどこまで増やせるかは今回測定しておらず、E002 で見たとおり DSQL の読み取り遅延そのものは Aurora writer の約4倍でした。読み取りの比率が非常に高いサービスは E002 の容量結果とあわせて判断する必要があります。
完了P1Issue #5
接続障害・サービスごとの復旧と成功したコミットの保持
同じ接続障害の後、業務の復旧・コミットの保持・再接続の負担はどうか?
結果 MVP: 30秒の接続遮断後、DSQL・A2 ともコミットの消失・重複0件、遮断解除後の再接続 0.02–0.07秒(DB フェイルオーバーは未測定)
要約と本番利用の観点を見る
この実験では、アプリケーションと DB の間の接続が一時的に切れたとき、接続が戻った後に正常な処理へ復帰するか、そしてすでに成功したコミットが消えたり二重に反映されたりしないかを確認しました。最小範囲(MVP)として、毎秒300件の注文業務を送っている最中に、負荷発生器から DB へ向かうパケットを30秒間破棄するよう経路を塞ぎました(ブラックホールルート)。これはクライアント側のネットワーク障害であり、DB 自体の障害やフェイルオーバー(failover)ではありません。
DSQL(D1)と Aurora Serverless v2(A2)のどちらも、遮断された30秒間のリクエストが接続エラーとタイムアウトで失敗し、150秒の測定区間全体の技術的失敗率は D1 20.6%、A2 20.7% でした。遮断時間が測定区間の20%であるため、遮断区間のリクエストはほとんど失敗し、残りの区間は正常に処理されたと解釈します。遮断を解除した後、新しい接続で最初の照会が成功するまで D1 は0.02秒、A2 は0.07秒でした。
最も重要な結果は整合性です。コミット応答を受け取れず成否が不明なリクエストは、業務 ID のレシートで確認してから再試行するように実装し、セル終了後にレシート・注文・元帳・在庫を突き合わせました。両サービスともコミットの消失、二重反映、在庫の不一致は0件でした。DSQL でも対照群と同じ方式(業務 ID のレシートとコミット有無の確認)を実装すれば、接続が切れた状況で整合性を守ることができました。
本番利用の観点
今回の試験範囲では、DSQL は接続が30秒切れても成功したコミットを失ったり二重に反映したりせず、接続が戻るとすぐに再接続しました。ただしこれはアプリケーションが業務 ID のレシートと「コミット有無が不明なときは確認してから再試行」を実装していたためで、この実装は DSQL と既存サービスの両方に必要です。遮断中のリクエストは両サービスとも失敗したため、復旧時間はネットワークが戻るまでの時間に左右されます。DSQL 内部の障害や AZ 障害での動作は、公開された障害注入手段がないため今回確認できず、Aurora のフェイルオーバー時間も測定していません。
完了P0Issue #6
バックアップ、ポイントインタイム復元、ミスからの復旧
DSQLの復旧機能・時間・作業量は既存サービスとどう異なるか?
結果 MVP: DSQL は PITR なし、バックアップ481秒+復元129秒でミス前の状態を回復。A2 PITR 587秒。両復元先のマーカー 30/30 正常
要約と本番利用の観点を見る
この実験では、運用者がデータを誤って変更した後、ミス以前の状態のデータを復元してアプリケーションが再び読めるようになるまでの手順と時間を、DSQL と Aurora Serverless v2(A2)で比較しました。最小範囲(MVP)として、約 100 MB のデータの上に1秒間隔のマーカー30個を書き、その後すべてのマーカーを -1 で上書きして新しい行を1つ挿入する「ミス」を起こし、各サービスの方法で復旧しました。
DSQL は任意の時刻に戻すポイントインタイム復元(PITR)をサポートしておらず、AWS Backup のフルバックアップから新しいクラスターに復元する方法しかありません。そのため、マーカーを書いた後、ミスの前にオンデマンドバックアップを取得しました。バックアップ(約 102 MB)に481秒かかり、このバックアップから新しいクラスターを作る復元ジョブは129秒でした。A2 はミス直前の時刻を指定してポイントインタイム復元し、復元されたクラスターの準備に223秒、インスタンスを追加して接続できるようになるまで587秒かかりました。
両方の復元先で、正常なマーカー30個とその合計が元と同じで、上書きされた行とミス後に挿入した行は0行でした。復元先への最初の接続には D1 343 ms、A2 291 ms かかりました。DSQL の復元は速かったものの、戻せる時点は「最後にバックアップを取得した時刻」に限られるため、バックアップ周期の間に生じた変更は失われます。
本番利用の観点
DSQL でもミスからの復旧は可能ですが、従来の Aurora のように「ミスの1秒前」に戻すポイントインタイム復元がないことが最大の違いです。復旧できる最新の状態は最後の AWS Backup 復旧ポイントなので、許容できるデータ損失時間(RPO)に合わせてバックアップ周期を決め、その費用を受け入れる必要があります。今回の小規模データではバックアップ8分、復元2分でしたが、バックアップは毎回フルバックアップのため、データが増えると時間と費用が増える可能性があります。復元は常に新しいクラスターに行われるため、アプリケーションの接続先と IAM 権限を新しいクラスターに切り替える手順も用意しておく必要があります。
完了P1Issue #7
データ増加と運用作業の影響
DSQLの DDL・診断・成長への対応はどれほど簡単で、制約は何か?
結果 MVP: 負荷中の1,100万行非同期インデックス736秒、ビルド中の書き込み p99 30.7→79.8 ms(SLO 内、失敗0)。5,000行トランザクション・310秒トランザクションは上限で拒否
要約と本番利用の観点を見る
この実験では、サービスの運用中にスキーマを変更したりインデックスを作成したりする作業が DSQL でどれほど簡単で、業務にどのような影響を与えるか、そして DSQL のトランザクション制約が実際にどのように現れるかを確認しました。最小範囲(MVP)として、E002 規模のデータがある DSQL クラスターに毎秒1,000件の注文業務を送りながらインデックス作成と列の追加・削除を実行し、同じ負荷だけを送ったセルと比較しました。対照群は今回測定していません。
注文1,100万行の status 列に CREATE INDEX ASYNC でインデックスを作成すると、コマンドは0.1秒で戻り、インデックスが実際に使える状態(indisvalid)になるまで736秒(約12分)かかりました。ビルドが進行した5分間の測定区間で、注文作成の p95 は 27.5 ms から 52.0 ms に、p99 は 30.7 ms から 79.8 ms に増え、注文履歴照会の p99 も 9.8 ms から 45.7 ms に増えました。それでもすべての業務が SLO 内にあり、失敗は0件、業務の不変条件違反も0件でした。続けて実行した列の追加・列の削除・インデックスの削除は、それぞれ0.1秒以内に終わりました。
DSQL の制約ははっきりと現れました。5,000行を1つのトランザクションで変更しようとすると「transaction row limit exceeded」(54000)で拒否され、トランザクションを310秒間開いたままにすると「transaction age limit of 300s exceeded」で拒否されました。大量の変更は3,000行以下に分け、5分を超える作業はトランザクションを分ける必要があります。E002 でもこの制約のためにロード・後片付けのコードを分割して書き、大量削除が遅いため測定方法を変える必要がありました。
本番利用の観点
運用中のインデックス追加と列の変更は、DSQL ではサービスを止めずに行えました。1,100万行のインデックスビルド中に書き込み遅延が2–3倍に増えましたが目標内で、失敗もありませんでした。ただしインデックスはコマンド終了後も約12分間使えないため、デプロイ手順で indisvalid を確認してから新しいインデックスに依存するコードを有効にする必要があります。3,000行と300秒のトランザクション上限は、大量の更新・削除や長いバッチ処理を複数のトランザクションに分けることを強いるため、既存のバッチやデータ移行スクリプトは書き直す必要があります。vacuum のような保守作業はユーザーが行う必要はありませんが、対照群との運用負担の比較はしていません。
完了P1Issue #8
DSQLと既存サービスの負荷急増への対応とアイドル後の再開
DSQLと既存のサーバーレス・固定容量サービスの遅延・手動介入・費用はどう違うか？
結果 MVP: 急増（最大2,000 TPS）時の失敗はDSQL・A2とも0件。15分アイドル後の最初の接続はDSQL 112–287 ms、自動一時停止したA2は15秒の接続タイムアウト超過2/2
要約と本番利用の観点を見る
この実験では、リクエスト量が急に増えたとき、または長くリクエストがなかった後に再び届いたときに、人が容量を調整しなくても遅延目標を守れるかを、DSQLとAurora Serverless v2（A2）で比較しました。最小範囲（MVP）として、基準1,000 TPSの20%（2分）→200%（1分）→100%（2分）→5%（1分）と到着率を変える急増負荷を1回送り、その後すべての接続を閉じて15分待ってから最初のリクエストを送るアイドル試験を2回行いました。
急増負荷では、両サービスとも手動介入なしですべての段階を失敗0件で処理しました。DSQLの注文作成p95は29.2–36.0 msで、到着率が10倍になってもほとんど変わらず、2,000 TPS段階のp99は51.5 msでした。A2は4–32 ACUの範囲でwriterが10.5 ACUから最大21 ACUまで増え、注文作成p95は8.2–12.1 ms、2,000 TPS段階のp99は37.9 msでした。この急増幅（最大2,000 TPS）はE002で測定した両サービスの容量より小さいため、容量限界での急増対応は今回の結果からは判断できません。
アイドル後の最初のリクエストでは大きな差が出ました。DSQLは15分間接続がなかった後でも、最初の接続112–287 ms、最初の照会115–123 msで応答し、その後の照会は約2 msに戻りました。A2はこの試験の間、最小容量を0 ACU、自動一時停止を300秒に設定しており、CloudWatchで実際に0 ACUまで停止したことを確認しました。この状態で最初の接続は2回ともドライバーの接続タイムアウト15秒以内に完了せず失敗し、その接続試行が再開を引き起こして約1分以内に容量が戻りました。
本番利用の観点
リクエストがまばらに届く、または夜間に止まるサービスでは、DSQLが明確に有利でした。DSQLは15分のアイドル後も最初のリクエストを0.3秒以内に処理し、アイドル中はコンピューティング料金がかかりません。Aurora Serverless v2も0 ACUの自動一時停止でアイドル費用をなくせますが、再開中に最初の接続が15秒を超えて失敗したため、接続タイムアウトとリトライを長めに設定する必要があります。今回の急増幅では両サービスとも手動介入なしで処理できたため、容量限界付近での急増対応はE002の容量結果と合わせて判断する必要があります。1回の実行、小規模データでの結果です。
完了P0Issue #9
同じ業務の費用と選択基準
DSQLの性能・利便性の利点には、どのような費用・制約が伴うか？
結果 MVP: DSQLはリクエスト100万件あたり約USD 0.31。RDS Multi-AZ（時間あたり約USD 1.22）との損益分岐は平均約1,100 TPS。8時間稼働+16時間アイドルの1日の費用はDSQL約USD 9 vs RDS約USD 29
要約と本番利用の観点を見る
この実験では、同じ業務と同じ遅延目標を守る場合に、DSQLと既存サービスの費用が負荷の形によってどう変わるかを計算しました。最小範囲（MVP）として、新たにAWSリソースを立ち上げず、E002（スループット・DPU・ACU）とE009（アイドル時の動作）で測定した値にソウルリージョンのオンデマンド単価を掛けました。業務はE002の注文の組み合わせ（商品照会40%、注文履歴30%、注文作成20%、キャンセル10%）です。
DSQLは処理した量だけDPUで課金され、この業務ではリクエスト1回あたり0.029–0.032 DPUを使いました。ソウルの単価（100万DPUあたり$10）でリクエスト100万件あたり約$0.31、1,000 TPSを1時間維持すると約$1.12です。一方、RDS Multi-AZ（db.r6g.xlarge、gp3 400 GiB）は負荷に関係なく時間あたり約$1.22で、SLO内で5,839 TPSまで処理しました。したがって平均負荷が約1,100 TPSより低ければDSQLが安く、それより高い負荷が続けば固定インスタンスが安くなります。Aurora Provisioned（writer+reader、時間あたり約$1.25 + I/O）も同様の損益分岐を示します。
負荷の形によって差は大きくなります。1,000 TPSで24時間一定の負荷では、1日の費用はDSQL約$27、RDS Multi-AZ約$29でほぼ同じでした。8時間だけ1,000 TPSで稼働し16時間休むサービスでは、DSQL約$9、RDS約$29で、DSQLは約3分の1でした。リードレプリカを置いたAurora Serverless v2（A2）はwriterとreaderが一緒に拡大するため1,000 TPSで時間あたり約$3.4となり、最小容量のためにアイドル時間にも課金されて1日約$53でした。0 ACUの自動一時停止を使うと約$27に下がりますが、E009では最初の接続が15秒を超えて失敗しました。
本番利用の観点
費用だけを見ると、DSQLは「リクエストが少ない、または不規則なサービス」に有利で、「高い負荷が一日中続くサービス」には不利です。今回の業務での損益分岐は平均約1,100 TPSでした。それより低い負荷では、固定インスタンスを常時稼働させる費用がなくなり、高可用性も標準で含まれるためDSQLが安くなります。逆に数千TPSを継続して処理すると、リクエスト数に比例するDPU料金が固定インスタンスを上回ります。大きな集計も処理量に応じて課金されるため（E012）、分析業務が多いサービスは別途費用を計算する必要があります。この計算は1つの業務の組み合わせ、オンデマンド単価、1回の測定値に基づく推定です。
完了P0Issue #10
DSQLの開発・運用のしやすさと導入負担
DSQLは初期導入・繰り返し運用の作業時間と修正量をどれだけ減らすか、または増やすか？
結果 MVP: インフラ作業は減った（作成32秒、容量・パスワード・vacuum・ルーティング不要）が、アプリ側の負担が増えた（SQL 16/35修正、リトライ・トランザクション分割・非同期インデックス・接続入れ替え・PITRなしへの対応）
要約と本番利用の観点を見る
この実験では、DSQLを導入するとインフラ運用の作業がどれだけ減り、その代わりにアプリケーションと運用手順にどのような負担が加わるかを整理しました。最小範囲（MVP）として、新たなAWS実行なしに、E001からE012までで4つのサービス（DSQL、RDS Multi-AZ、Aurora Provisioned、Aurora Serverless v2）を実際に作成し、データを投入し、負荷をかけ、復旧し、削除する中で経験した作業を集めました。計画にあった作業ごとの時間測定と3回の再実行は行っていないため、作業時間の削減率は計算していません。
インフラ側の作業はDSQLのほうが明確に少なくなりました。DSQLクラスターは作成リクエストから32秒で使用可能になり、削除は約2分でした。Aurora Serverless v2（writer+reader）は作成に約11分、削除に約15分かかりました。DSQLにはインスタンスサイズや最小・最大容量を選ぶ手順、保存するパスワード、vacuumのようなメンテナンス設定、読み取り・書き込みのルーティングがなく、2万4千TPSまで負荷が増えても容量を調整する必要がありませんでした。
一方、アプリケーション側の負担はDSQLで増えました。業務SQL 35個のうち16個を修正する必要があり（E001）、コミット時の競合をリトライするコードが必須でした（E004）。トランザクションは3,000行と300秒を超えられないため、データ投入・削除・バッチのコードを分割する必要があり（E002、E008）、非同期インデックスは完了を別途確認する必要があり、外部キー側のインデックスを手動で作成する必要がありました。接続は1時間ごとに入れ替えてIAMトークンに署名する必要があり（E003）、ポイントインタイム復元がないため、誤操作からの復旧はバックアップ周期に縛られました（E007）。
本番利用の観点
DSQLは「DBサーバーを運用する作業」を大きく減らします。容量計画、インスタンスの入れ替え、パスワードのローテーション、vacuum、readerルーティングを気にする必要がなく、クラスターの作成も30秒余りでした。その代わり、その負担のかなりの部分がアプリケーションに移ります。既存のPostgreSQLコードはSQL修正、リトライ、トランザクション分割、接続入れ替えを設計し直す必要があり、ポイントインタイム復元がない分、バックアップ周期と復旧手順を別途決める必要があります。新しく作るサービスが最初からこの制約に合わせて設計するなら利点は大きく、ストアドプロシージャや大量バッチが多い既存サービスを移行すると負担が大きくなります。作業時間は測定していません。
完了P0Issue #11
DSQLの大規模な照会・集計とOLTPへの干渉
DSQLの大きなクエリの性能・OLTPへの干渉・チューニングの負担は？
結果 MVP: 1,100万行の全体集計 約36秒（約1,700 DPU）、110万行の集計 2.4–2.6秒。集計の繰り返し中もOLTP失敗0、注文作成p99 30.7→41.8 ms
要約と本番利用の観点を見る
この実験では、DSQLで大きなJOIN・集計クエリにどれだけ時間と費用がかかるか、そしてそのようなクエリを注文業務（OLTP）と同時に実行するとOLTPがどれだけ遅くなるかを確認しました。最小範囲（MVP）として、計画のL規模の代わりにE002のS規模のデータ（注文1,100万行、注文品目2,750万行）で選択度の異なる4つのクエリを実行し、毎秒1,000件のOLTP負荷の中で集計を繰り返す干渉試験を行いました。対照群は今回測定していません。
インデックスを使う顧客ごとの最近の注文20件のJOINは、30回の実行でp50 4.4 ms、p95 32.9 msでした。注文の10%（約110万行）を日付別に集計するクエリは2.4–2.6秒、注文1%の範囲の注文品目（約27万行）で商品ランキングを付けるwindowクエリは0.7秒、注文1,100万行全体をステータス別に集計するクエリは約36秒かかりました。同じクエリを2回実行した結果、行数と結果ハッシュは同じで、2回目も1回目とほぼ同じ時間がかかり、繰り返し実行による高速化の効果は見られませんでした。
DSQLはクエリが処理した量だけDPUで課金します。分単位の使用量から推定すると、全体集計1回に約1,700 DPU（約$0.017）、10%集計1回に約100–150 DPUかかりました。毎秒1,000件のOLTP負荷を送りながら10%集計を休みなく繰り返した（5分間で124回、p50 2.4秒）ところ、OLTPは失敗0件でSLOを守り、注文作成のp95は27.5 msから32.0 msに、p99は30.7 msから41.8 msに、商品照会のp99は6.9 msから16.4 msに増えました。
本番利用の観点
DSQLではインデックスを使う照会は速いものの、数百万行以上を走査する集計は数秒から数十秒かかり（1,100万行で約36秒）、トランザクションの300秒上限のため、より大きな集計は分割して実行する必要があります。サーバー側の statement_timeout と文のキャンセルが機能しないため（E001）、長時間かかるクエリを途中で止める手段も限られます。集計を繰り返してもOLTPは目標内で処理され、干渉は小さいものでした。ただし集計は処理したデータ量に応じてDPU料金が発生するため、定期レポートやダッシュボードのように大きな集計が頻繁な業務は、分析用のストアに分離するほうが費用面で安全です。対照群との速度比較は行っていません。
完了P1Issue #12
何を、どのように比較するのか
DSQLの優位を前提にしません。同じ業務・整合性・SLOを満たした結果で判断します。
- 性能
- 期限内に成功した処理量とp95/p99の遅延。接続・再試行の時間を含め、繰り返し測定のばらつきを公開します。
- 使いやすさ
- 初回接続・移行・拡張・診断・復旧の実作業時間、手動介入と修正量。初期学習と繰り返しの運用を区別します。
- 費用と制約
- 同じ要件を満たす成功業務あたりの費用。未対応の機能・未測定の項目を明示し、終了後はすべての実験用リソースを削除します。