神话破灭！AI 复刻人类不过级数据库，4.6万测试全过，却被一条SQL打回原形！|翻译|代码|源码|postgresql_网易订阅

“如果不选定该选什么数据库，神话试全先用 PostgreSQL 准没错。破灭”PostgreSQL 源于 1986 年加州大学伯克利分校的复刻 POSTGRES 项目，历经近四十年的人类往往代，因其极致的不过被条可靠性、数据完善性、数据库超强扩展性以及对 SQL 原则的测l网高度合规而享誉业界，被誉为“世界上最先进的回原开源关系型数据库”。时间来到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的状况，这是重写的状况。01四次“盖新房”我们来看看 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 $02AI为什么不行？这四次尝试，最后达成了文章开头描述的成效，听起来特别厉害，特别震撼。人类花了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 可以高效高效阅读代码，可以生成代码，甚至可以实现令人震惊的大规模重构。然而，它还无法生成几十年的工程经验。