MongoDB 用 Claude 辅助开发 ExtendDB 的 DynamoDB 兼容后端

MongoDB 近日发布了一款面向 AWS ExtendDB 的存储后端，让原本只能在 AWS 上运行的 DynamoDB 工作负载可以直接落地到 MongoDB 之上，应用代码无需改动。这项工作最初源自 MongoDB 内部「Skunkworks」黑客周的一次实验，工程师借助 Anthropic 的 Claude Code 在极短时间内完成原型，随后又经过数周与 AWS 团队的协作才正式合入。

项目背景：从黑客周实验到正式合入

AWS 在今年早些时候开源了 ExtendDB：一款 DynamoDB 兼容的协议适配器，核心思路是把 DynamoDB 的线协议与底层存储解耦，用户可以替换为其他后端。在此之前，DynamoDB 工作负载只能在 AWS 上运行，跨云、本地或隔离环境都缺乏可行路径。

MongoDB 团队注意到 ExtendDB 后，在黑客周期间尝试用 Claude Code 一次性生成 MongoDB 后端实现。工程师在文中坦承，Claude 并没能「一击命中」，但它「走得比预想中远得多」——到午餐时间，一个 prompt 已经演化出真正可用的组件雏形。之后团队花了数周时间，与 AWS 团队一起走完 RFC 流程和多轮代码评审，最终把这块后端合入主线。

技术实现：DynamoDB 语义如何映射到 MongoDB

MongoDB 与 DynamoDB 在数据模型层面具有天然相似性：DynamoDB 的 item 本质上是属性集合，MongoDB 的文档模型同样是灵活的 JSON-like 结构，因此多数 item 可以直接映射到 MongoDB 文档，无需引入额外的「翻译层」。

在具体实现上，MongoDB 后端做了如下映射：

• 键与查询：DynamoDB 的分区键和排序键映射为带类型的 MongoDB 字段；Query 和 Scan 操作映射为 MongoDB 的 filter、sort 与分页。
• 二级索引：DynamoDB 索引拆成独立的 MongoDB 集合，与基础 item 保持同步。
• 条件写与事务：条件表达式映射为后端条件检查；事务性写操作借助 MongoDB 的 session transaction，保证 item、索引和 stream 变更的原子性。
• Streams：DynamoDB 流事件映射为 MongoDB 流记录文档，序列号在与数据变更同一事务中分配。
• 冲突与一致性：DynamoDB 的可重试冲突映射为 MongoDB 的冲突重试；支持的一致性读使用主节点读与多数写，全局二级索引上的强读则被显式拒绝。

并非所有概念都能干净映射。例如 DynamoDB 数字最高支持 38 位精度，而 MongoDB 的 Decimal128 仅支持 34 位；DynamoDB 底层还会把数字存为字符串，若直接下发会破坏数值比较。因此涉及数值比较的查询，团队选择在 Rust 层完成比较逻辑，再将结果下发到 MongoDB。

运行时的灵活性

借助 MongoDB 作为存储后端，ExtendDB 的覆盖范围被显著拓宽。MongoDB 既可以在 AWS、Azure、GCP 三大公有云上以托管服务方式部署，也支持跨云集群，还能在自有数据中心、隔离环境甚至笔记本上自托管。把 MongoDB 放到 ExtendDB 之后，DynamoDB 工作负载可以跟随 MongoDB 部署到任意位置，应用侧代码保持不变。

文中特别强调，这一组合面向的不只是云原生团队，也包括航空、制造、零售、医疗等对网络中断或离线运行有刚性需求的行业：只要 DynamoDB 的访问模式不变，就可以在原本无法触达的环境中继续工作。

AI 在其中的角色

MongoDB 在文末直言「没有 AI 这件事就不会发生」。他们的判断是：在传统开发模式下，给 ExtendDB 写一个 MongoDB 后端属于体量过大的产品级工作，很难在季度计划之间被随手捡起；而 Claude 把这个实验的「经济学」彻底改变——一个想法可以在很短时间内走到有产品价值的阶段，再由工程师补齐后续的工程化、合规与跨团队协作。

文章同时提醒读者，AI 生成的代码只是故事的一部分，真正让项目落地的仍是那位提出问题的工程师、允许团队腾出时间的组织机制，以及后续与 AWS 数周的合作打磨。MongoDB 公开了对应的 RFC 与设计文档，欢迎社区反馈与缺陷报告。