AWS前提で書かれたアプリケーションを、AWSの外で動かしたい。そう考えたとき、最初に突き当たるもののひとつがDynamoDBである。リレーショナルDBなら移行先はいくらでもあるが、あの独特なNoSQLの「代わり」は、AWSの外にあるのか。
先に結論を書く。当社はDynamoDB互換のOSS「ExtendDB」とPostgreSQLの組み合わせを2段階で検証し、動くことを確認したうえで、進行中のプロジェクトの技術スタックとして正式に採択した。アプリのコードはほぼそのまま、接続先を差し替えるだけで移行できる。ただし、導入前に知っておくべき明確な欠点もあった。
本稿では、採択に至った理由と検証の中身、そしてその欠点を順に書く。DynamoDBからの移行先を探している人の判断材料になれば幸いである。
前提 — 我々が置かれていた状況
EastCloudでは、デジタル庁がOSSとして公開した政府向け生成AI「源内」を、国産のさくらのクラウド上で動かせるかを検証するプロジェクトを進めている（経緯は1本目の記事にまとめた）。1本目で「チャット履歴などの永続化は初期範囲から外した」と書いたが、本稿はその宿題を回収する話である。
源内のWeb部分（源内Web）は、公式リポジトリでアーキテクチャ図が公開されている。
図の右側にある通り、チャットやエージェントの実行履歴の保存先はDynamoDBである。我々の条件は2つあった。第一に、データは国内の自分たちの管理下に置きたい。第二に、源内Webは公開後も更新が続くOSSなので、上流の更新に追従し続けられる形にしたい。この条件で、DynamoDBの受け皿を探すことになった。
この記事の主役になる用語（知っている方は読み飛ばしてください）
DynamoDB
AWSのフルマネージドなNoSQLデータベース。表の形を厳密に設計するリレーショナルDBと違い、キーに対して柔軟な形のデータを高速に出し入れする用途に向く。バックアップやスケールをAWSが面倒見てくれるため、AWS上のアプリでは定番の保存先になっている。
ExtendDB
AWSが2026年5月にオープンソース（Apache 2.0ライセンス）として公開した、DynamoDB互換のAPIアダプタ。DynamoDBと同じ「話し方」（ワイヤプロトコル）を実装しているため、アプリはDynamoDB用のSDKのまま、接続先だけを差し替えて使える。実データは裏側のデータベース（最初の対応はPostgreSQL）に保存される。
マネージドDB
データベースサーバの構築・バックアップ・監視・アップグレードといった運用を、クラウド事業者が肩代わりしてくれる提供形態。対義語は「セルフホスト」で、こちらは自分でサーバを立てて自分で面倒を見る。
移行先の二択
DynamoDB前提のコードをAWSの外で動かす方法は、実質的に2つに絞られる。
| 方針 | 具体例 | 強み | 弱み |
|---|---|---|---|
| リレーショナルDBへ再設計する | TiDB / MySQL互換、PostgreSQL | 運用ノウハウが豊富。SQLで検索・集計しやすい | 上流の更新のたびに、DynamoDB前提のコードを翻訳し直す |
| DynamoDB互換のAPI層を挟む（今回の採択） | ExtendDB + PostgreSQL | アプリのコードをほぼそのまま残せる | 互換層とDBの両方を自分で運用する |
当社が採択したのは後者、ExtendDB + PostgreSQLである。
決め手は上流への追従だった。源内Webは公開後も更新が続くOSSで、当社の検証実装はそれに追従し続ける必要がある。リレーショナルDBへ再設計する方式だと、上流がDynamoDB前提のコードを変更するたびに、こちらの翻訳もやり直しになる。互換APIを挟む方式なら、その影響を互換層の中に閉じ込められる。移行のゴールが「一度きりの引っ越し」なら再設計も十分に有力だが、「追従し続ける」なら互換層が有利、という判断である。
ExtendDBとは何か
ExtendDBは、AWS自身が2026年5月20日に公開したOSSで、Rust製のDynamoDB互換APIアダプタである。DynamoDBのワイヤプロトコルを実装しているため、AWS SDKやCLIは接続先を変えるだけでそのまま動く。保存先はプラグイン式で、最初のバックエンドとしてPostgreSQL（14以上）が提供されている。
対応範囲は、テーブル操作、項目の読み書き、Query / Scan、バッチ処理とトランザクション、Streams、TTLなど、DynamoDBの主要なAPIに及ぶ。一方で、グローバルテーブル、リージョン間レプリケーション、オートスケーリングは実装されていないと公式が明記している。
ここは押さえておきたい。ExtendDBは「DynamoDBのAPIを話す翻訳機」であって、「DynamoDBというマネージドサービス」の代わりではない。バックアップも監視もアップグレードも、翻訳機とその裏のPostgreSQLの両方について、自分でやることになる。
検証 — 手元で通し、さくらの仮想サーバで通す
検証は2段階で行った。ExtendDBはv0.1.1を固定して使った。
段階1（手元の開発環境）。 源内互換のAPI経由で、チャット・メッセージ・実行履歴の作成・取得・更新・削除が一通り動くことを確認した。各コンポーネントを再起動してもデータが残ること、依存先が落ちたときに正しくエラーになることも確認している。アプリ側はDynamoDB用のデータアクセスコードのままで、接続先の変更だけで動いた。
段階2（さくらのクラウドの仮想サーバ）。 同じ構成一式をさくらのクラウドの仮想サーバへ持ち込み、同じ操作が同じ結果になることを確認した。手元で動くことと、実際に載せたい環境で動くことは別問題なので、この段階を分けている。
2段階の検証がいずれも成功したことをもって、ExtendDB + PostgreSQLを本プロジェクトの技術スタックとして正式に採択した。
明確な欠点 — 秘密情報が「カタログDB」に集まる
ここからが、導入を検討する人に一番伝えたい話である。検証の過程で、明確な欠点がひとつ見つかった。
ExtendDBは、自分の動作に必要な管理情報を「カタログ」と呼ばれる領域に保存する。実体はPostgreSQL上のデータである。検証したv0.1.1では、このカタログに次の2つが保存される。
- 裏側のPostgreSQLへ接続するための情報（パスワードを含む）
- 互換APIのアクセスキーを暗号化するための鍵
つまり、守りたい暗号文と、それを開ける鍵が、同じ場所に置かれる。例えるなら、金庫と金庫の鍵が同じ引き出しに入っている状態だ。しかも、この引き出しごと複製するのがバックアップなので、バックアップを取るほど「鍵と接続情報のコピー」も増えていく。カタログを読めてしまう相手には、暗号化はほとんど効かない。
マネージドのDynamoDBを使っている限り、この心配はAWSの認証基盤が肩代わりしてくれていた。ExtendDBに乗り換えるということは、この心配がまるごと自分の仕事になる、ということでもある。
この欠点が実害になるのは、「カタログを読める人」が現れたときである。逆に言えば、対処の方向は2つしかない。鍵を別の場所へ移して同居を解消するか、カタログへ到達できる相手を絞るかだ。前者はExtendDB本体の改修が必要になるため、ソースを改変しない方針の当社は、後者を選んだ。
具体的には、ExtendDBとPostgreSQLに外部から直接届くアドレスを与えず、プライベートネットワークへ隔離して、アプリからの決められた通信だけを通す。こうすると、カタログへ到達しうる相手は「インターネット全体」から「ネットワークの内側＋承認済みの経路」まで縮む。金庫の鍵を引き出しから出せないなら、引き出しのある部屋に施錠して入れる人を決める、という考え方である。
ただし、これは欠点の解消ではなく緩和である。ネットワークの内側に侵入された場合や、バックアップそのものを持ち出された場合には効かない。だからバックアップの保管先も、同じ水準の管理下に置く必要がある。
このほかに、運用面の負担も挙げておく。
- 運用が二層になる。ExtendDBとPostgreSQLの両方について、バックアップ・監視・アップグレードを自分で設計する
- マネージド機能はない。自動スケールも自動バックアップも、DynamoDBでは意識しなかったものを自前で用意する
- 互換層のバージョン管理。ExtendDB自体の更新への追従計画が必要になる
なお、検証が通ることと本番で使えることは別である。バックアップと復旧、性能、運用体制は、それぞれの要件で確認してから本番に載せてほしい。当社もその検証はこれからである。
さくらのクラウドで使う場合の位置づけ
誤解のないように書いておくと、さくらのクラウドにマネージドDBがないわけではない。TiDB互換のオンデマンドDBや、データベースアプライアンスといったリレーショナル系の選択肢は用意されている。見当たらないのは、マネージドのNoSQLである（2026年7月の検証時点）。
だから、DynamoDB前提の資産をさくらのクラウドへ持ち込むなら、道は二択の表のとおりになる。リレーショナルへ再設計してマネージドDBに乗るか、ExtendDBのような互換層を自分で立てるか。今回の我々は上流への追従を優先して後者を選んだが、追従の必要がない一度きりの移行であれば、再設計してマネージドに乗るほうが運用は軽い。資産の量と運用体制で答えは変わる。
検証結果の賞味期限
本稿の検証は2026年7月、ExtendDB v0.1.1を固定して行った。ExtendDBは2026年5月の公開から約3か月でv0.1.10までリリースを重ねており（2026年8月26日時点）、月数回ペースの更新が続いている。さくらのクラウド側も機能追加が速い。本稿で挙げた欠点や未実装機能も、読んでいる時点では状況が変わっているかもしれない。判断の前に、最新のリリースノートと公式ドキュメントを確認してほしい。
まとめ
- DynamoDB前提のコードをAWSの外で動かす現実的な道は「リレーショナルDBへ再設計」か「互換API層を挟む」かの二択
- 上流の更新に追従し続けたいなら互換層が有利。ExtendDB + PostgreSQLは、手元とさくらの仮想サーバの2段階検証で動作を確認し、正式に採択した
- 明確な欠点がある。接続情報と暗号化の鍵が「カタログDB」とそのバックアップに集まるため、ネットワーク隔離などの対策を最初から設計に織り込む
- マネージドのDynamoDBが肩代わりしていた運用（バックアップ・監視・スケール）は、すべて自分の仕事になる
- 検証成功と本番運用は別物。バックアップ・復旧・性能は、自分の要件での確認を
「DynamoDBの代わりになるか」という冒頭の問いに戻るなら、答えはこうなる。APIの代わりにはなる。マネージドサービスの代わりには、自分がなる。
よくある質問
Q1. ExtendDBとは何か
AWSが2026年5月にオープンソース（Apache 2.0）として公開した、DynamoDB互換のAPIアダプタである。DynamoDBのワイヤプロトコルを実装しており、DynamoDB用のSDKやCLIは接続先の変更だけで使える。実データは裏側のデータベース（最初の対応はPostgreSQL）に保存される。
Q2. ExtendDBはDynamoDBと完全に互換か
主要なAPI（テーブル操作、項目操作、Query / Scan、バッチ、トランザクション、Streams、TTLなど）に対応するが、グローバルテーブル、リージョン間レプリケーション、オートスケーリングは実装されていないと公式が明記している。マネージドサービスとしての運用機能は利用者側で用意する。
Q3. 既存のDynamoDB用コードはどのくらい書き換えが必要か
本稿の検証では、アプリ側のデータアクセスコードはそのままで、接続先（エンドポイント）の変更だけで動作した。ただし利用しているDynamoDB APIがExtendDBの対応範囲に収まっているかは、事前の確認が必要である。
Q4. ExtendDBを本番運用するときの注意点は何か
検証したv0.1.1では、PostgreSQLへの接続情報とアクセスキー暗号化用の鍵が、カタログDBとそのバックアップに保存される。カタログを読める相手を絞るため、ネットワーク隔離を前提に設計したい。加えて、ExtendDBとPostgreSQLの二層について、バックアップ・監視・アップグレードを自分で運用する必要がある。
Q5. さくらのクラウドにDynamoDB互換のマネージドサービスはあるか
2026年7月の検証時点では見当たらない（NoSQL系のマネージドDB自体が見当たらなかった）。なお、マネージドDB自体はある（TiDB互換のオンデマンドDBなど。いずれもリレーショナル系）。DynamoDB互換が必要なら、ExtendDBのような互換層を仮想サーバ上で自分で動かすことになる。
Q6. 互換API層とリレーショナルDBへの再設計は、どちらを選ぶべきか
元のアプリの更新に追従し続ける必要があるなら互換層、一度きりの移行で自分たちのスキーマを育てていくなら再設計が向く。再設計ならマネージドDBに乗れるため、運用は軽くなる。
参考リンク
- ExtendDB — GitHub
- Introducing ExtendDB: An open source DynamoDB-compatible adapter with pluggable storage backends — AWS Database Blog（2026-05-20）
- ExtendDB 公式サイト
- digital-go-jp/genai-web — GitHub
- 源内Web アーキテクチャ（公式ドキュメント）
- さくらのクラウド マニュアル
- 政府AI「源内」はさくらのクラウドで動くのか — OSS公開から3か月、国産クラウドでMVPを動かすまで
- さくらのクラウドにCloudFrontの「あの404対策」はない — SPA deep linkの壁とAppRunゲートウェイという現実解
