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，像浏览任何其他表那样浏览它。

更新于