用 Rust 重写的 Postgres，现在已通过 100% 的 Postgres 回归测试

原文 ↗ Hacker News 讨论 ↗

AI 与“真正的”重写

  • 许多人希望明确区分 AI 驱动的重写与人工重写；也有人认为质量和验证比作者是谁更重要。
  • 一些人把“用 LLM 用 Rust 重写”看作一种梗或风格化项目，通常由一个人快速完成，没有长期维护计划。
  • 另一些人则认为这是一个重要的概念验证，展示了大规模语言迁移如今已变得多么便宜，并可能推动现代化（例如 COBOL 时代的系统）。

测试、可靠性与“生产伤疤”

  • 通过 Postgres 100% 的回归测试被认为很了不起，但许多人强调这只能证明没有已知回归。
  • 反复出现的担忧：
    • 真正的可靠性来自多年的生产事故和“伤疤组织”，而不仅仅是测试。
    • 测试不会覆盖每一条成功路径、并发边界情况或性能角落。
    • 过度拟合测试是可能的，尤其是对 LLM 而言。
  • 有人建议进行差分测试（同时运行两个数据库并比较输出）、基于属性的测试、模糊测试、Jepsen 风格测试，以及把 bug 报告挖掘成新测试。

Rust、内存安全与性能

  • 支持者：Rust 的安全模型和“每连接一个线程”的架构可能简化内部实现、减少共享内存复杂性，并释放更好的并行能力。
  • 批评者：这里存在成千上万处 unsafe 使用（尤其是解析器），因此许多 C 风格风险仍然存在；如果它这么不安全，有人会问“为什么还要用 Rust”。
  • 项目作者声称：
    • 当前已发布版本比 Postgres 慢约 8 倍。
    • 一个尚未发布的新版本在事务型工作负载上快约 50%，在分析型工作负载上快约 300%，采用列式存储和批处理执行，在 clickbench 上比 ClickHouse 慢约 2 倍。

许可与合法性

  • 这个移植版本采用 AGPL；一些人不喜欢从宽松的 Postgres 许可转向 copyleft。
  • 争论 LLM 生成的翻译究竟是衍生作品、新作品，还是根本不受版权保护；线程中的共识是“法律上很模糊”，但上游若是宽松许可，大概允许更严格的外层封装。

维护、信任与生产使用

  • 许多人认为这更像一个有趣的实验或学习工具，而不是现在就能“运行多年”的生产系统。
  • 担忧包括：
    • 单一作者的 bus factor。
    • 数千个 AI 生成提交的可审查性。
    • 长期社区、扩展生态以及向后兼容升级。
  • 也有人提出一种积极用途：把这类重写放到真实工作负载上运行，找出缺失的测试，并把改进反馈回上游 Postgres。