ExtendDB：AWS 开源的 DynamoDB 协议适配器，把 DynamoDB 跑在 Postgres/Cassandra 上
阅读时间: 大约 10 分钟
ExtendDB：AWS 开源的 DynamoDB 协议适配器，把 DynamoDB 跑在 Postgres/Cassandra 上
2026 年 5 月 20 日，AWS Database Blog 发布了一篇题为《Introducing ExtendDB: an open source DynamoDB-compatible adapter with pluggable storage backends》的公告。这件事本身就很反常：一家云厂商主动开源一个工具，帮用户把原本跑在自家 DynamoDB 上的工作负载搬到 PostgreSQL、Cassandra 甚至本地笔记本上。本文基于 extenddb.org 官网与发布公告，拆解它到底是什么、怎么工作、以及官方自己标注的成熟度边界。
一、背景：为什么 AWS 要「反向导流」
DynamoDB 是 AWS 最早的 NoSQL 托管服务之一，以单-digit 毫秒级延迟和无缝扩容著称，但它的代价是深度锁定：SDK、数据模型、TTL、Stream 都绑定在 AWS 上，本地开发要起一个 DynamoDB Local，企业要私有化或混合云部署则几乎没有官方路径。
ExtendDB 的叙事正是补这个缺口。官方原话是「Run DynamoDB workloads anywhere（在任何地方跑 DynamoDB 负载）」，并把自己 maintainer 署名为 AWS。Koala 的点评点破了背后的商业逻辑：DynamoDB 的 API 本身就是护城河——只要开发者习惯了这套 SDK 与数据模型，真正大规模、要求极致弹性的负载最终还是会回到 AWS；而 ExtendDB 先把开发者留在「DynamoDB API」这一侧。这是一种「宽进严出」的生态策略，而不是真的要放弃 DynamoDB。
二、是什么：一个适配器，不是一个数据库
ExtendDB 官网用一张图说清了定位——「An adapter, not a database（是适配器，不是数据库）」：
你的应用（任意 DynamoDB SDK）
│
▼
ExtendDB（API 适配器，Rust 编写）
│
┌────┼─────────────┐
▼ ▼ ▼
PostgreSQL Cassandra 其他可插拔后端
(参考后端) (pluggable) (pluggable)一个 DynamoDB 客户端把 API 请求发给 ExtendDB；ExtendDB 翻译每条请求，路由到你选择的存储后端。应用侧使用任意 DynamoDB SDK，唯一要改的就是 endpoint_url——从 https://dynamodb.us-east-1.amazonaws.com 改成 http://localhost:8000，业务代码一行不动。
技术栈上，ExtendDB 用 Rust 编写，线协议直接讲 DynamoDB，开源协议为 Apache 2.0（带明确专利授权）。官方列出已支持的操作面相当全：CRUD、Query、Scan、批量操作、事务（transactions）、Streams、表达式（expressions）与 TTL。
三、两种后端，成熟度并不对等
这是官方页面上最值得标注的口径差异：
- PostgreSQL 是「reference backend（参考后端）」，官方明确说它「against the full ExtendDB test suite 做过校验」，是行为对齐最完整的实现；
- Cassandra 是「pluggable（可插拔）」后端，定位是「for scale（面向规模）」；
- 其他后端通过同一套公开接口接入，目前属于社区贡献范畴。
换句话说，官方自己就承认：想生产环境跑，PostgreSQL 路径是被完整测试套件背书的；Cassandra 路径主打横向扩展，但成熟度、行为对齐程度要打个问号，需要自行验证。
Koala 条目里给出的性能口径是：PostgreSQL 模式下单条操作延迟低于 10ms，Cassandra 模式可横向扩展到每秒数千请求。需要说明的是，这两个数字来自 Koala 周报摘要（转述官方口径），我在官网 FAQ 上尝试展开「How does performance compare to cloud DynamoDB?」一条时未能取到完整基准文本，因此这里按「官方称 / 约」处理，读者做容量规划时应以自己的压测为准——毕竟延迟主要由后端（PG/Cassandra）与部署环境决定，ExtendDB 这层翻译开销是叠加项而非全部。
四、浏览器里的 WASM 引擎
ExtendDB 官网上一个比较有工程说服力的细节是 Playground：整个 ExtendDB 引擎被编译成 WebAssembly（约 1MB，打开页面时下载），在浏览器内存里跑起一个完整的 DynamoDB 引擎——可以建表、put item、query，甚至跑向量检索，无需安装、无需 AWS 账号。截图里那笔 PUTITEM 请求返回 200 OK · 3 MS，数据持久化在浏览器本地存储中。
这意味着两件事：其一，ExtendDB 的核心是一个足够小、无外部依赖的 Rust 库，才能塞进 WASM；其二，它的分发形态不只有 Docker 镜像（extenddb/extenddb）和 npm 包（@extenddb/dev），还能作为嵌入式引擎跑在任何地方——这对边缘、离线、断网场景是真实的卖点。
五、适用与不适用场景
适合：
- 本地开发与 CI：在笔记本上跑高保真的 DynamoDB API，不依赖网络和 AWS 账号；
- 混合云/私有化：把 DynamoDB 接口跑在团队已经运维的 PostgreSQL 上，不引入新依赖；
- 断网/边缘环境：工厂、门店、车辆、远程站点，不依赖云连接也能跑。
不适合：
- 期待「ExtendDB 性能 = 云 DynamoDB」的团队：它只是协议翻译层，持久性、可用性、扩容能力全部继承自你选的后端；
- 重度依赖 DynamoDB 专属托管特性（如全局表、DAX 加速、特定 IAM 策略深度联动）的工作负载——ExtendDB 对齐的是线协议操作面，不等于对齐全部托管能力；
- 把 Cassandra 后端当生产默认值的团队——官方把它定位为可插拔扩展后端，行为对齐程度需自行验证。
六、客观分析：优势与局限
优势： AWS 亲自维护 + Apache 2.0 + Rust 编写，工程可信度高；「只改 endpoint」的迁移路径对存量 DynamoDB 应用非常友好；WASM 嵌入式形态打开了边缘/本地的新用法；同一套代码可在云、本地、私有化之间复用，合规友好。
局限： 它不提供自己的存储引擎，性能与可靠性完全取决于后端；PostgreSQL 之外的后端成熟度参差；事务、Stream 等高级语义在不同后端上的一致性需要实测；长期看，把数据从 DynamoDB 迁出来容易，但要再迁回去或迁到第三个系统，仍要面对自己的数据模型债务。
七、它意味着什么
ExtendDB 的价值不在于「干掉 DynamoDB」，而在于给 DynamoDB 生态补上了自托管与本地开发这一块长期缺失的拼图。对被 DynamoDB SDK 绑定、但又有私有化/合规/离线需求的团队，它是一条几乎零代码改动的退路；对云厂商而言，这是一次精明的生态防守——把开发者体验做宽，把最终负载留在自己的 API 范式里。是否值得为它改写存储后端，取决于你的瓶颈究竟是「锁定」还是「性能」。