Pgrust的构建：四次用AI将Postgres重写为Rust的尝试

在过去的三个月里，我与朋友Jason Seibel合作构建了pgrust，目标是通过AI打造一个更好的Postgres版本。由于Postgres用C语言编写，AI在修改时容易出错，因此我们首先将其重写为Rust，以便AI更安全地添加新功能。这一观点正在被证实——正在开发的第五版pgrust在事务负载上比Postgres更快，分析查询性能与Clickhouse相当，而Clickhouse通常比Postgres快数百倍。

我们共进行了四次尝试，总花费约10万美元。第一次尝试pgrust-og采用逐个功能移植的方法。首先构建核心子系统（解析器、计划器、执行器等），然后利用多个Codex代理并行实现数百个功能。测试通过率达到了96%，但由于计划器的内部表示与Postgres存在细微差异——例如在Postgres中一个简单的SELECT查询被表示为单个节点（SeqScan），而在Rust中被表示为三个节点（Projection、Filter、SeqScan），并且表引用方式也不同——导致“器官移植失败”，最终无法修复。这次尝试消耗了8个Codex账户一个月的费用，约1600美元。

第二次尝试使用c2rust将Postgres的C代码直接转译为530万行不安全Rust。转译后的代码完全通过了测试套件，甚至与Postgres扩展ABI兼容。但将其重构为安全Rust极为困难：每个函数都使用指针，要转换一个函数必须同时修改其调用者和被调用者的类型和逻辑，导致修改一个函数可能涉及数百个函数。尝试增量方法（如为每个函数创建安全和不安全两个版本）均不奏效。

第三次尝试pgrust-idiomatic计划逐crate重写c2rust的输出（约1000个crate）。受Jarred Sumner将Bun从Zig逐文件重写为Rust的启发，我们开始了这项工作。然而，由于需要重写所有crate才能运行测试，风险极高，且效率问题依然存在。

最终，第四次尝试通过同时运行多达40个并行子代理，实现了文件级别的重写，生成了180万行惯用Rust代码。关键教训包括：重写遗留系统时应选择文件级而非功能级并行；使用CI处理构建负载；确保中间表示与原始系统等价。最终版本pgrust不仅证明了AI辅助重写的可行性，也为未来AI安全扩展Postgres奠定了基础。