一个由个人维护的开源项目,把用Rust重写的Postgres实现推到了100%通过46,066条官方回归测试的节点,还能直接读取现有Postgres 18.3的数据目录启动。这是pgrust项目公布的最新进展。数字看着很唬人,但翻开项目自己的说明,"非生产就绪""未做性能优化""主流扩展不兼容"几个字也写得清清楚楚——这恰恰是这次进展最值得琢磨的地方:一份漂亮的测试成绩单,和一个规模不大、离能用还有距离的项目,同时成立。

从67%到100%,这个数字到底测了什么

pgrust不是一夜之间冒出来的。作者此前发过阶段性博客,进度从67%的回归测试通过率,一路推进到这次的100%,同时也通过了隔离测试(isolation tests)。46,066条查询是Postgres官方用来验证SQL行为一致性的标准回归测试集,通过意味着pgrust在语法解析、查询执行、返回结果这些层面,和原版Postgres 18.3表现一致。

这不是小工程。Postgres的C代码库历史悠久、体量庞大,内存安全隐患、扩展生态复杂、vacuum机制笨重,是业内公认的老毛病。用Rust整个重写一遍还要对齐行为,难度不低。

但回归测试测的是单机、单会话下的SQL语义正确性,不覆盖并发压力、崩溃恢复、大规模扩展调用这些真正决定数据库能不能上生产的场景。测试通过率100%,说明的是"长得像Postgres",不等于"扛得住Postgres级别的负载"。

170颗星背后:谁会真的用它

GitHub上的pgrust仓库,现在大概170颗星、6个fork、1个未解决issue。这个体量,更像是一个个人项目在小圈子里被围观,离获得广泛社区背书还差得远。

项目自己也没回避这一点。维护者明确写着当前阶段目标是"缩小性能差距",没有说要超越或持平原版性能。更硬的限制是PL/Python、PL/Perl、PL/Tcl等主流过程语言扩展目前不兼容——这几个扩展是很多真实Postgres部署的硬依赖,缺了它们,pgrust短期内基本进不了生产环境的候选名单。

  • 风险.扩展生态不兼容意味着现有企业用户几乎无法平迁,pgrust目前的用户画像更接近愿意折腾的技术爱好者和好奇的开发者,而不是要换库的运维团队。

它和Neon、CockroachDB不是一回事

数据库领域"兼容Postgres"早就是常见打法,但打法各不相同。Neon官方文档直接讲"Neon就是Postgres",本质是原版内核加云原生存储层;CockroachDB和RisingWave走的是协议兼容路线,语法上对齐但底层语义不同,CockroachDB官方文档就列了一长串不支持的特性,比如CREATE DOMAIN、range类型、外部数据封装器;libSQL则是SQLite的分支,跟Postgres不是一个谱系。

pgrust的路子和这几家都不一样:它不是套一层协议壳,而是试图把Postgris的行为本体重写一遍。这条路风险更高——重写意味着要复刻几十年积累下来的边角行为,任何一个细节偏差都可能在生产环境炸出问题;但潜在的回报也更大,如果真能做成,拿到的是一个内存安全、更容易做深层架构改动的数据库内核,而不是又一个兼容层。

测试通过率是入场券,不是及格证。

AI辅助编程和许可证,两个没讲透的变量

项目反复提到用了AI辅助编程来加速这次重写,但具体AI在哪个环节介入生成代码、怎么验证正确性,目前没有更多细节披露。如果这个说法属实,pgrust会是观察"AI加速大型遗留系统重写"这个趋势的一个早期样本——用几个人的团队,在相对短的周期里,把一个体量巨大的C语言项目重写并跑通官方测试集,这在过去很难想象。

另一个容易被忽略的变量是许可证。pgrust用的是AGPL-3.0,这类许可证对云厂商二次分发有额外的合规要求,商业化路径不如MIT或Apache宽松。这会直接影响云数据库厂商愿不愿意跟进或采纳,也是决定这个项目未来能走多远的现实门槛。

路线图里列的多线程内核、内置连接池、no-vacuum存储设计,方向都戳中了Postgres长期被诟病的痛点,但眼下这些还只是路线图条目,不是已经交付的能力。接下来真正该盯的,是有没有真实工作负载的性能基准公布,扩展兼容能不能往前推进,以及社区规模会不会真的扩大。