用 Rust 重写的 Postgres，已通过 100% 的 Postgres 回归测试
文章摘要
pgrust 是 malisper 用 Rust 重写 PostgreSQL 的一个雄心勃勃的项目，目标是”让数据库从内部更容易被修改”，同时借助 Rust 的内存安全和现代工具链。项目定位为在功能上与 PostgreSQL 18.3 兼容。
在兼容性上，pgrust 做到了：磁盘格式与现有 Postgres 18.3 数据目录兼容，并在 46000 多条回归查询上匹配 Postgres 的输出——这正是标题所称”通过 100% 回归测试”的由来。项目明确标注尚未达到生产可用、尚未做性能优化。目前大多数 Postgres 扩展（PL/Python、PL/Perl、PL/Tcl 等过程语言扩展）还不兼容，只移植了部分自带的 contrib 模块。开发方式被作者概括为”Rust 加 AI 辅助编程”。
值得注意的是，README 的更新区块提到了一个尚未公开发布的高性能版本：它采用”每连接一线程（thread-per-connection）”而非 Postgres 传统的”每连接一进程”模型，并声称在事务型负载上快约 50%、在分析型负载上快约 300 倍。这些数字目前无法验证，也未随 v0.1 一起发布。项目采用 AGPL-3.0 强 copyleft 许可。
围绕这个项目，HN 上真正被反复辩论的其实不是数据库本身，而是一个更大的时代命题：“AI 重写”算不算一次真正的重写，以及”通过全部回归测试”能否等同于”值得信任”。作者 malisper 也在评论区亲自回应了扩展兼容性等问题。
HN 评论精华
- juliangmp 开门见山：”我觉得我们需要严格区分’重写’和’AI 重写’。”这条评论引爆了整场讨论。colordrops 反问：如果你无法分辨黑盒里是顶级开发者还是 AI 写的代码，这种区分还有意义吗？dwedge 则反击道，”slop（垃圾代码）”这个词之所以流行起来，恰恰说明大家分辨得出来；而且大多数人并非顶级开发者，AI 让人能轻易吐出成千上万行代码，好坏比例只会恶化。
- “通过回归测试 ≠ 正确” 是最有共识的技术批评。多人引用 Dijkstra 名言”测试只能证明 bug 存在，不能证明其不存在”，并强调回归测试套件只是”多年生产事故的疤痕集合”，无法覆盖全部行为。27183 一针见血：真正的检验是”在生产环境跑得和原版一样久”，而这恰恰是最难的——因为没人真正理解这个新东西是怎么工作的，维护会是噩梦。mbrock 估算，要为 Postgres 写出一份可作为验证依据的参考语义，涉及并发事务的指称语义等新发现，可能需要 30–60 年博士级工作量，因此现实中只能靠差分测试、模糊测试和验收测试。
- 关于”AI 是否胜任重写”，阵营分裂明显。jatins、rjh29 认为重写恰是 LLM 的强项——枯燥的翻译式苦力活，人反而容易出错（Ladybird 的 JS 引擎 Rust 移植就是逐字节对比、双跑生产后才发布的正面例子）。反方 OtomotO 主张”AI 是平均水平的程序员”（因为它学的是全网代码而非 Carmack、Bellard 这类天才的代码），引出了一长串关于”LLM 学的是分布而非平均值”的争论。
- 也有人质疑项目的现实意义。ottavio 尖锐地说：”除了因为它是 Rust 写的，开发者凭什么在玩具项目之外用它？”并批评”用 Rust 重写一切”的风气反映出部分 Rust 社区是”软件塔利班”而非交付可靠成果的工程师。flanked-evergl 则从项目可持续性角度指出：代码不等于一个有社区、贡献者、用户和资金的开源项目。
- 作者 malisper 亲自回应扩展问题：理论上 Rust 版 Postgres 可以支持扩展——只要让相关函数和结构体与 Postgres 保持 ABI 兼容——但一旦涉及 C 指针和 C 字符串，几乎所有代码都得写成 unsafe。jeltz 补充说 Postgres 根本没有正式的扩展 API，扩展能调用内部几乎任何部分，所以只能重写。
- 关于 AGPL 许可，Ameo 说了句很有时代感的话：”当这个软件本质上就是约 1000 美元的 Claude 额度加约 40 小时开发者提示与筛选的产物时，这 10 万行代码用什么许可证究竟还重要吗？copyleft 和整个软件许可生态，只有在生产软件真正需要大量人类努力和投入时才有意义。”