DynoTable
中階閱讀時間 4 分鐘

ExtendDB：在你自己的資料庫上執行 DynamoDB API

假設有一套醫院病歷系統必須留在院內——患者資料絕不能 離開本地網路，每一個依賴項都要經審計員簽字放行，而 開發膝上型電腦根本沒有網際網路。團隊已經照著 DynamoDB API 寫好了應用，也很滿意：個位數毫秒級的鍵查詢、乾淨的 項目模型、無需照看的 schema 遷移。但託管版 DynamoDB 是一項 雲服務，而「把資料發到 AWS」在這裡是行不通的。

ExtendDB 正是為填補這一空缺而生。它講的是 DynamoDB 線路協議，但把資料存進你自己執行的資料庫裡。

ExtendDB 是什麼？

ExtendDB 是 AWS 的開源介面卡（用 Rust 編寫），它在你自己執行的資料庫（例如 PostgreSQL）之上實現了 DynamoDB JSON 線路協議。你現有的 AWS SDK 和 AWS CLI 都能原封不動地繼續工作——變的只有 endpoint URL——於是你既拿到了 DynamoDB API，又不必把資料發到託管雲服務。

ExtendDB 是一個來自 AWS 的開源介面卡——由 AWS DynamoDB 工程師編寫，並 在 AWS 資料庫部落格上釋出—— 它用 Rust 實現了 DynamoDB JSON 線路協議。因為它 響應的是與託管服務相同的 HTTP API，你現有的 AWS SDK 和 AWS CLI 都能原封不動地工作。唯一要變的就是 endpoint URL—— 無需重寫程式碼，也無需新的用戶端庫。

有意思的是那個 API 背後是什麼。ExtendDB 擁有可插拔的 儲存後端：PostgreSQL 是參考實現，Cassandra 則被 提到是另一個可能的後端。新後端 無需修改核心即可實現，因此 DynamoDB 相容層 和儲存層可以各自獨立演進。

所以一次請求是這樣流動的：

DynamoDB JSON 線路協議讀 / 寫你的應用（AWS SDK 不變）ExtendDB（Rust 介面卡）PostgreSQL（你的資料，你的磁碟）

它支援什麼——又不支援什麼

根據入門文件和那篇釋出公告， ExtendDB（v0.1）覆蓋了大多數應用實際會呼叫的操作：

  • 表——Create、Delete、Describe、List、Update。
  • 項目——Put、Get、Delete、Update（包括 SET / REMOVE / ADD / DELETE 更新動作）。
  • Query 和 Scan——鍵條件、、投影、 分頁和次要索引。
  • 批次——BatchGetItem 和 BatchWriteItem。
  • ——TransactGetItems 和 TransactWriteItems。
  • 、、匯入/匯出和標籤。

它有意不實現的，是那套 DynamoDB 專屬的託管功能——最典型的就是全域性表和 跨區域複製。那些是託管服務全球基礎設施的屬性， 而不是 API 表面的屬性，所以它們不會帶到一個由你 自己託管的介面卡裡。

對比 DynamoDB Local

你可能已經在用 DynamoDB Local 做離線開發了。那是一個單獨的 JAR（或 amazon/dynamodb-local Docker 映象），面向單機上的 單元測試。ExtendDB 的目標比那個單程序工具更寬廣：本地 開發、本地部署、邊緣與氣隙環境，以及那些你想要 DynamoDB API、但資料要存在你自己掌控的 基礎設施裡的混合/多雲場景。

對比託管版 DynamoDB

這是 AWS 明確劃出的界線，而且很重要：

ExtendDB 不是 DynamoDB。它是一個相容實現，而不是託管服務的 替代品。效能特徵、擴充套件行為和營運屬性都有所不同。

具體來說，當你執行 ExtendDB 時：

  • 資料庫的可用性和備份由你負責。沒有託管的 多可用區永續性或時間點恢復替你打理——那是你 和你的 PostgreSQL 營運的事。
  • endpoint 上強制啟用 TLS。
  • 憑證類似 IAM，但獨立於 AWS IAM——ExtendDB 有自己的 憑證模型；它不會對著你的 AWS 帳戶做認證。

它是 v0.1，採用 Apache 2.0 許可。請把它當作早期軟體：用在 上面那些環境裡很棒，但不是能直接替換生產規模託管版 DynamoDB 的方案。

ExtendDB 本身不計量 RCU 或 WCU — 容量是 PostgreSQL 的問題。當相同的 API 呼叫按需命中 us-east-1 中的託管 DynamoDB，1 KB PutItem 賬單 1 WCU 和 4 KB GetItem 賬單 0.5 RCU 最終一致。延遲基準 ExtendDB；使用 pricing calculator 比較什麼是雲對於相同的訪問模式，賬單看起來會像這樣。

搭建

ExtendDB 執行在 Linux 和 macOS 上，需要 Rust 1.85+ 和 PostgreSQL 14+。流程是兩條命令：

extenddb init
extenddb serve

init 會在你的 PostgreSQL 資料庫裡預置 schema；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>'}
});

用戶端配置之外的一切——PutItem、Query、TransactWriteItems—— 都和你針對託管版 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 指向 ExtendDB 的 endpoint，方式和 你把它連到 DynamoDB Local 一樣：用 ExtendDB 的埠和 一次性憑證建立一個離線（本地）設定檔案，然後 DynoTable 就能瀏覽、查詢和編輯這些項目——只不過現在它們背後是你自己 磁碟上的 PostgreSQL，而不是某個 JAR 的記憶體儲存。

這就是線路協議相容帶來的回報： SQL Workbench、視覺化查詢構建器和項目 編輯，全都能原封不動地針對 ExtendDB 工作，於是你不用寫 scan 指令碼就能擁有一個真正的 GUI 來看你自託管的資料。

有一個要提前規劃的注意點：ExtendDB 的 endpoint 只支援 HTTPS，而 DynoTable 的離線設定檔案（和多數 DynamoDB-Local 環境一樣）指向的是迴環 host:port。如果你的用戶端或工具鏈需要一個明文的迴環監聽埠， 請在 ExtendDB 前面終止 TLS（或者跑一個本地反向代理），再把 GUI 指向它——不管怎樣，線路上的協議依然是 DynamoDB JSON。

陷阱

  • 別把 v0.1 當成生產版 DynamoDB。擴充套件性、延遲和永續性 都是你的 PostgreSQL 的，不是 AWS 的。在依賴它之前，請針對你的 工作負載做基準測試。
  • 沒有全域性表 / 跨區域複製。如果你的設計依賴 多區域雙活，ExtendDB 不是這條路——那是託管服務 的功能。
  • 底層資料庫要你自己備份。沒有託管的 PITR；一個 被刪掉的 PostgreSQL 卷就是沒了。請像對待任何其他 PostgreSQL 那樣 接上 pg_dump / WAL 歸檔。
  • 憑證是 ExtendDB 自己的，不是 AWS IAM。別指望用 IAM 策略、 角色或條件鍵來管控訪問——那套授權模型不會 帶過來。

後續步驟

  • 先給你的訪問模式建模——不管後端是 DynamoDB 還是 PostgreSQL-via-ExtendDB，同樣的單表設計 紀律都適用。
  • 用 DynamoDB 運算式構建器構建並 檢查你的讀寫，然後用 DynamoDB-JSON 轉換器在普通 JSON 和 線路格式之間轉換測試資料。
  • 等你準備好去戳一個真實的 ExtendDB 例項時，連上 DynoTable，像瀏覽任何其他表那樣瀏覽它。

已更新