“如果不确定该选什么数据库，先用 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 倍！
这些数据看起来太厉害了，所以一旦发布，立刻就在HackerNews上掀起了热烈讨论。
AI 真的这么强了吗？ 都能写“真正”的数据库了吗？
很快，一位数据库领域的大神出手了。
Andreas Seltenreich 是 SQLsmith 的作者。
SQLsmith 是 PostgreSQL 社区非常著名的 SQL 模糊测试工具。
它不像普通测试那样执行固定 SQL，而是像一个疯狂的机器人：不断随机生成各种复杂、诡异、人类几乎不会手写的 SQL，然后丢给数据库执行。
目的只有一个：拷打数据库，尽量把它搞崩溃。
就在 pyrust 发布后不久，Andreas 开始测试它，仅用一条SQL，就把pyrust打回了原形：
SELECT numrange_subdiff(1,1);
在 PostgreSQL 中正常返回 0
但是pyrust 直接返回：Segmentation fault ！进程访问了非法内存，被操作系统强制终止。
这件事情有点儿讽刺，因为 Rust 最大的卖点之一，就是内存安全。
结果一个“以 Rust 内存安全为核心卖点”的数据库，在处理 C 版本 PostgreSQL 可以正常处理的 SQL 时，却发生了内存崩溃。
当然，这不是Rust的问题，这是重写的问题。
0 1
四次“盖新房”
我们来看看 pyrust 是怎么创造出来的， Michael Malis 和 Jason Seibel 的 10 万美元是怎么花掉的。
1.第一次尝试：拿着说明书盖新房
方法：把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 $
0 2
AI为什么不行？
这四次尝试，最终达成了文章开头描述的效果，听起来非常厉害，非常震撼。
人类花了30年才搞成的事情，AI 用10万美元，3个月就搞定了。
但是，“通过 100% 的官方回归测试”与“具备工业级数据库的可靠性”之间，隔着一条难以跨越的鸿沟。
Andreas 的测试正好说明了这一点，除了那个Segmentation Fault之外，Andreas还发现了好几个其他问题，例如MERGE 语句内部错误、 查询优化器内部状态异常、二进制数据输入没有完整验证等
这些问题说明：把 PostgreSQL 翻译成 Rust，并不等于重新获得 PostgreSQL 30年的可靠性。
数据库太复杂了，并且运行在极其复杂的硬件、内存和并发环境下，那 46,000 个测试，能保证主流路径能跑通，但根本无法穷尽复杂的死角。
过去30年的bug修复、测试经验、社区反馈、边界案例等宝贵的知识并没有完全包括在其中。
可能有人说，如果回归测试非常完善，包含了各个犄角旮旯的东西，而pyrsut通过了这些所有的测试，是不是就可以和postgresql媲美了？
我觉得很难，一方面是数据库功能太多，很难穷尽；
另一方面有很多东西回归测试难以覆盖，比如性能、内存占用、长时间稳定性、升级兼容性等。
写这篇文章的时候，我想起之前写过的一篇文章：《》，里面讨论的是 Linux 内核维护者面临的问题。
两个故事其实很像，Linux 内核也好，PostgreSQL 也好，它们真正珍贵的东西，并不仅仅是代码。
几十年时间里，无数 Bug 修复、失败经验、线上事故、工程取舍、知识沉淀...... 这些东西隐藏在代码背后。
AI 可以快速阅读代码，可以生成代码，甚至可以完成令人震惊的大规模重构。
但是，它还无法生成几十年的工程经验。
热门跟贴