AI重写PostgreSQL：通过4.6万测试，一条SQL崩溃暴露工程鸿沟

“如果不确定该选什么数据库，先用 PostgreSQL 准没错。”

PostgreSQL 源于 1986 年加州大学伯克利分校的 POSTGRES 项目，历经近四十年迭代，因其极致的可靠性、数据完整性、超强扩展性以及对 SQL 标准的高度合规而享誉业界，被誉为“世界上最先进的开源关系型数据库”。

时间来到 2026 年，AI 编程能力越来越强，一位管理过 PB 级 PostgreSQL 集群的数据库专家 Michael Malis，产生了一个大胆的想法：

PostgreSQL 已经发展了几十年，历史包袱越来越重。为什么不借助大模型，把它重新设计一遍？

这件事情不容易，只精通数据库不行，于是他找了一个有 AI 背景的朋友 Jason Seibel，两人合作，准备大干一场。

经过 3 个月的折腾、4 次大版本迭代、烧掉 10 万美元的 API 费用后，他们终于推出了 pgrust：一个用 Rust 重写的 PostgreSQL。

pgrust 发布的成绩单堪称神迹：

• 完全兼容：基于 PostgreSQL 18.3，甚至可以直接挂载现有的 Postgres 18.3 数据目录启动！
• 满分通关：100% 通过了 PostgreSQL 官方回归测试套件（46,000+ 个测试），连极难搞定的事务隔离测试也全过！
• 性能狂飙：在 OLTP 事务型负载下比原版快 50%；在 OLAP 分析型查询下，性能直接飙升 300 倍！

这些数据看起来太厉害了，所以一经发布，立刻就在 Hacker News 上掀起了热烈讨论。

AI 真的这么强了吗？都能写“真正”的数据库了吗？

很快，一位数据库领域的大神出手了。

Andreas Seltenreich 是 SQLsmith 的作者。

SQLsmith 是 PostgreSQL 社区非常著名的 SQL 模糊测试工具。它不像普通测试那样执行固定 SQL，而是像一个疯狂的机器人：不断随机生成各种复杂、诡异、人类几乎不会手写的 SQL，然后丢给数据库执行。目的只有一个：拷打数据库，尽量把它搞崩溃。

就在 pgrust 发布后不久，Andreas 开始测试它，仅用一条 SQL，就把 pgrust 打回了原形：

SELECT numrange_subdiff(1,1);

在 PostgreSQL 中正常返回 0，pgrust 却直接返回：Segmentation fault！进程访问了非法内存，被操作系统强制终止。

这件事情有点儿讽刺，因为 Rust 最大的卖点之一，就是内存安全。结果一个“以 Rust 内存安全为核心卖点”的数据库，在处理 C 版本 PostgreSQL 可以正常处理的 SQL 时，却发生了内存崩溃。当然，这不是 Rust 的问题，这是重写的问题。

四次“盖新房”

我们来看看 pgrust 是怎么创造出来的，Michael Malis 和 Jason Seibel 的 10 万美元是怎么花掉的。

第一次尝试：拿着说明书盖新房

• 方法：把 PostgreSQL 按功能划分，让 AI 为每个子系统进行设计、开发。
• 刚开始进展非常惊人，很快达到 96% 的回归测试率。然而，Rust 版本抽象出的数据模型与原版 PostgreSQL C 语言的模型不一致，当推进到最复杂的 Query Planner（查询规划器，约 5 万行核心逻辑）时，这种隐性矛盾彻底爆发。

拿着一个说明书盖新房，外观功能都一样，但内部墙体管线和老宅不兼容，装不下老宅的中央供暖主机（Planner），砸墙重建成本过高，放弃。

花费：~1600$

第二次尝试：全量机械翻译

• 方法：用 c2rust 这个工具，把 PostgreSQL C 源码直接转为 Rust。
• 结果非常震撼，两天生成了 530 万行 Rust，测试 100% 通过，甚至 PostgreSQL 扩展也能兼容！但是代码完全不可维护，转译出来的 530 万行代码中，所有变量和函数参数基本都是 *mut 或 *const 裸指针，并且必须包裹在 unsafe 块中。把 C 语言里的潜在风险，换了一种方式搬到了 Rust。

相当于把老宅整体搬过来，试图原位把木头一根一根换成钢筋。结果一动其中一根关键木头（裸指针），整座房子就因为承重依赖全塌了。

花费：成本可忽略

第三次尝试：重新设计

• 方法：建立一个全新的干净代码库，仅把 c2rust 转译出的代码和 C 源码作为 AI 的“参考蓝本”。把 Postgres 拆成 ~1000 个 Rust Crate，让 AI 逐个 Crate 重新用纯正的 Safe Rust 从零编写。构建了 AI 技能与动态工作流，让 AI 组团（数十/上百个 Agent 并发）去分工编写、审计和修复各个 Crate。
• 但是不同的 AI Agent 在独立重构不同 Crate 时，对同一个 C 数据类型的翻译完全发散了！

相当于看着老宅图纸，在旁边一块砖一块砖盖全新的钢筋混凝土新房。

费用：~50000 $

第四次尝试：加入严格审计

• 方法：采用了“缝合点优先”策略（把致命隐患消灭在萌芽状态），把前三次尝试产生的所有代码、架构经验，以及一本详尽的技术债日志全部喂给 AI。与此同时，大幅升级了自动化审计规则，专门让 Agent 巡检“缝合点类型是否发散”、“代码是否符合 Rust idiomatic 规范”。

依然是让上百个施工队（Dynamic Workflows）同时盖全新的钢筋混凝土大楼，但这次旁边配备了极度严苛且精密的施工监理（Audit Skill）。

费用：~50000 $

AI 为什么不行？

这四次尝试，最终达成了文章开头描述的效果，听起来非常厉害，非常震撼。

人类花了 30 年才搞成的事情，AI 用 10 万美元，3 个月就搞定了。

但是，“通过 100% 的官方回归测试”与“具备工业级数据库的可靠性”之间，隔着一条难以跨越的鸿沟。

Andreas 的测试正好说明了这一点，除了那个 Segmentation Fault 之外，Andreas 还发现了好几个其他问题，例如 MERGE 语句内部错误、查询优化器内部状态异常、二进制数据输入没有完整验证等。这些问题说明：把 PostgreSQL 翻译成 Rust，并不等于重新获得 PostgreSQL 30 年的可靠性。

数据库太复杂了，并且运行在极其复杂的硬件、内存和并发环境下，那 46,000 个测试，能保证主流路径能跑通，但根本无法穷尽复杂的死角。过去 30 年的 bug 修复、测试经验、社区反馈、边界案例等宝贵的知识并没有完全包括在其中。

可能有人说，如果回归测试非常完善，包含了各个犄角旮旯的东西，而 pgrust 通过了这些所有的测试，是不是就可以和 PostgreSQL 媲美了？我觉得很难，一方面是数据库功能太多，很难穷尽；另一方面有很多东西回归测试难以覆盖，比如性能、内存占用、长时间稳定性、升级兼容性等。

几十年时间里，无数 Bug 修复、失败经验、线上事故、工程取舍、知识沉淀……这些东西隐藏在代码背后。AI 可以快速阅读代码，可以生成代码，甚至可以完成令人震惊的大规模重构。但是，它还无法生成几十年的工程经验。