中級読了 3 分

ExtendDB:自前のデータベース上でDynamoDB APIを動かす

ある病院の記録システムが建物の中に留まらなければならないとします — 患者データはオンプレミスのネットワークから決して出られず、監査人がすべての依存関係を承認し、開発用のラップトップにはそもそもインターネットがありません。チームはすでにDynamoDB APIに対してアプリケーションを書いており、それを気に入っています。1桁ミリ秒のキー検索、きれいなアイテムモデル、面倒を見るべきスキーママイグレーションがないことなどです。しかしマネージドのDynamoDBはクラウドサービスであり、ここでは「データをAWSに送る」というのは論外です。

ExtendDBはまさにそのギャップのために作られています。DynamoDBのワイヤプロトコルを話しますが、データはあなたが運用するデータベースに保存します。

ExtendDBとは何か

ExtendDBはAWSのオープンソースアダプターで — AWS DynamoDBのエンジニアによって書かれ、AWS Database Blogで発表されました — DynamoDB JSONワイヤプロトコルRustで実装しています。マネージドサービスと同じHTTP APIに応答するため、既存のAWS SDKとAWS CLIは変更なしで動作します。動くのはendpointのURLだけです — コードの書き直しも、新しいクライアントライブラリも不要です。

興味深いのは、そのAPIの背後にあるものです。ExtendDBにはプラガブルなストレージバックエンドがあります。PostgreSQLがリファレンス実装で、Cassandraも別の可能なバックエンドとして挙げられています。新しいバックエンドはコアを変更せずに実装されるので、DynamoDB互換レイヤーとストレージレイヤーは独立して進化します。

つまりリクエストは次のように流れます:

DynamoDB JSON wire protocolreads / writesYour app (unchanged AWS SDK)ExtendDB (Rust adapter)PostgreSQL (your data, your disk)

何をサポートし、何をサポートしないか

getting-startedドキュメントと発表によれば、ExtendDB(v0.1)はほとんどのアプリケーションが実際に呼び出す操作をカバーしています:

  • テーブル — Create、Delete、Describe、List、Update。
  • アイテム — Put、Get、Delete、Update(SET / REMOVE / ADD / DELETEの更新アクションを含む)。
  • QueryとScan — キー条件、フィルタ式、プロジェクション、ページネーション、セカンダリインデックス。
  • バッチBatchGetItemBatchWriteItem
  • トランザクションTransactGetItemsTransactWriteItems
  • StreamsTTLImport/ExportTags

意図的に実装していないのは、DynamoDB固有のマネージド機能のセットです — 最も顕著なのはGlobal Tablesリージョン間レプリケーションです。これらはAPI表面ではなくマネージドサービスのグローバルインフラの性質なので、自分でホストするアダプターには引き継がれません。

DynamoDB Localとの比較

オフライン開発にすでにDynamoDB Localを使っているかもしれません。あれは1台のマシンでのユニットテストを意図した単一のJAR(またはamazon/dynamodb-localのDockerイメージ)です。ExtendDBはその単一プロセスのツールより広くを狙っています。ローカル開発、オンプレミスのデプロイ、エッジやエアギャップ環境、そしてDynamoDB APIを使いたいがデータは自分が管理するインフラに置きたいハイブリッド/マルチクラウド構成などです。

マネージドDynamoDBとの比較

これはAWSが明示的に引いている線であり、重要です:

ExtendDBはDynamoDBではありません。互換実装であり、マネージドサービスの代替ではありません。パフォーマンス特性、スケーリングの挙動、運用上の性質は異なります。

具体的には、ExtendDBを動かすとき:

  • データベースの可用性とバックアップはあなたが所有します。 マネージドなマルチAZの耐久性やポイントインタイムリカバリが代わりにやってくれることはありません — それはあなたとあなたのPostgreSQL運用次第です。
  • endpointではTLSが必須です。
  • 認証情報はIAMライクですがAWS IAMとは別物です — ExtendDBは独自の認証情報モデルを持ち、あなたのAWSアカウントに対して認証しません。

これはv0.1で、ライセンスはApache 2.0です。初期段階のソフトウェアとして扱ってください。上記の環境には適していますが、本番規模のマネージドDynamoDBへのドロップイン置換ではありません。

セットアップ

ExtendDBはLinuxとmacOSで動作し、Rust 1.85+PostgreSQL 14+を必要とします。流れは2つのコマンドです:

extenddb init
extenddb serve

initはPostgreSQLデータベースにスキーマをプロビジョニングします。serveはワイヤプロトコルサーバーを起動し、https://127.0.0.1:8000のようなendpointでリッスンします(TLSが必須なのでhttpsです)。

任意のカスタムendpointと同じようにAWS SDKをそこへ向けます — URLと認証情報が変わるだけです:

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

クライアント設定より先のすべて — PutItemQueryTransactWriteItems — はマネージドDynamoDBに対して書くコードと同一です。シングルテーブルのアイテムレイアウトはクラウドとまったく同じように機能します:

PKSKtypebackendcreatedAt
TENANT#acmeAUDIT#2026-06-24eventpostgres2026-06-24T09:00:00Z
TENANT#acmeAUDIT#2026-06-24beventpostgres2026-06-24T09:01:12Z
TENANT#betaAUDIT#2026-06-24eventpostgres2026-06-24T09:02:40Z

DynoTableでの実践

ExtendDBはDynamoDBのワイヤプロトコルを話すので、専用の管理ツールは要りません — DynoTableを、DynamoDB Localに接続するのと同じ方法でExtendDBのendpointへ向けてください。ExtendDBのポートと使い捨ての認証情報でオフライン(ローカル)プロファイルを作成すれば、DynoTableがアイテムを閲覧・クエリ・編集します — ただし今やそれらはJARのインメモリストアではなく、自前のディスク上のPostgreSQLに支えられています。

これがワイヤプロトコル互換の見返りです。SQL Workbench、ビジュアルクエリビルダー、アイテム編集のすべてが変更なしでExtendDBに対して機能するので、scanスクリプトを書かずにセルフホストのデータに対する本物のGUIが得られます。

計画しておくべき注意点が1つあります。ExtendDBのendpointはHTTPSのみですが、DynoTableのオフラインプロファイルは(ほとんどのDynamoDB Local構成と同様に)ループバックのhost:portを対象とします。クライアントやツールがプレーンテキストのループバックリスナーを必要とする場合は、ExtendDBの前段でTLSを終端する(またはローカルのリバースプロキシを動かす)か、GUIをそこへ向けてください — いずれにせよワイヤ上のプロトコルは依然としてDynamoDB JSONです。

落とし穴

  • v0.1を本番のDynamoDBとして扱わないでください。 スケーリング、レイテンシ、耐久性はAWSのものではなくあなたのPostgreSQLのものです。依存する前に自分のワークロードでベンチマークしてください。
  • Global Tables / リージョン間レプリケーションはありません。 設計がマルチリージョンのアクティブ-アクティブに依存しているなら、ExtendDBは選択肢ではありません — それはマネージドサービスの機能です。
  • 基盤となるデータベースは自分でバックアップしてください。 マネージドなPITRはありません。削除されたPostgreSQLボリュームは消えます。他のPostgreSQLと同じようにpg_dump / WALアーカイブを組んでください。
  • 認証情報はExtendDB独自のもので、AWS IAMではありません。 IAMポリシー、ロール、条件キーがアクセスを統制すると期待しないでください — その認可モデルは引き継がれません。

次のステップ

  • まずアクセスパターンをモデル化してください — バックエンドがDynamoDBであれExtendDB経由のPostgreSQLであれ、同じシングルテーブル設計の規律が当てはまります。
  • 読み書きをDynamoDB Expression Builderで構築・確認し、フィクスチャをDynamoDB-JSONコンバーターでプレーンなJSONとワイヤ形式の間で変換してください。
  • ライブのExtendDBインスタンスを触る準備ができたら、DynoTableを接続し、他のテーブルと同じように閲覧してください。

更新日