pgrust是一个用AI将PostgreSQL重写为Rust的开源项目！
malisper/pgrust是一个非常有意思的数据库底层重构项目：它尝试用 Rust 重新实现 PostgreSQL（简称 Postgres）。目标不是做一个简单的数据库玩具，而是在保持 PostgreSQL 行为兼容的基础上，把这个运行了几十年的数据库核心换一种更容易修改、更容易实验的实现方式
pgrust 的目标是与 Postgres 18.3 兼容，并且在超过 46,000 次回归查询中与 Postgres 的预期输出相匹配。
pgrust 与 Postgres 磁盘兼容，可以从现有的 Postgres 18.3 数据目录启动。
目标是让 Postgres 更容易从内部进行更改：保持 Postgres 的行为模式，保持真正的 Postgres 测试作为预言机，并使用 Rust 和 AI 辅助编程来探索更深层次的服务器更改。
用C语言修的古老城市
PostgreSQL的江湖地位不用多说，开源数据库里的顶梁柱，功能强到没有朋友。但它的岁数也摆在那，核心代码大部分是C语言写的，经历过几十年的全球程序员轮番“添砖加瓦”。这座数字城市功能齐全，但地下的管线，也就是它的内部机制，复杂得就像一个巨型毛线球。
这就带来了一个让所有开发者头疼的问题：想改点里面的东西，难如登天。比如你想优化一下事务系统，或者给存储层加点新特性，你得先变成一个考古学家，去理解那些可能比你还大的历史代码。修一根水管就可能把整个街区的供水搞停，这种风险谁也担不起。
pgrust的想法很简单，与其在老城墙上打洞，不如干脆在旁边按照现代图纸，重建一座新城。他们选的材料是Rust，这种语言最大的卖点就是安全，它能在你写代码的时候，就帮你挡住了一大批内存越界、指针乱飞这种C语言里司空见惯的“常规操作”。对数据库这种需要7x24小时高负荷运转的软件来说，这个价值没法用钱衡量。
复制行为的挑战赛
很多号称“重新实现”数据库的项目，最后都沦为了玩具，最大的问题就出在“表面像，里子不像”上。
数据库最难复制的，其实不是SQL语法本身。真正要命的地方在于，你执行一万条查询，结果是不是每条都一模一样，哪怕是个空格？事务隔离级别下的诡异现象，是不是也和原版一致？报错信息是不是同一个字都不差？甚至在一些极端边缘情况下，行为是不是完全相同？
PostgreSQL里有一个隐藏规则，你执行下面这条SQL：
sql
SELECT NULL = NULL;
这种细节如果没处理好，任何一个依赖PostgreSQL特定行为的应用，迁移过来就会莫名其妙地崩掉。pgrust最聪明的做法，就是把原版PostgreSQL当成标准答案，直接用PostgreSQL自己那套庞大到令人发指的回归测试套件来验证自己。根据项目页面显示，它目前已经通过了全部46,066项测试，这意味着它不再是模拟，而是在努力成为一个真正的、可以互换的PostgreSQL。
用Rust重建内脏器官
Rust让数据库开发者心动的原因，就是它把C语言手里的那把“双刃剑”给收了。C语言给你极致速度和掌控权，但也给你自由去捅娄子，常见的比如内存泄漏、悬垂指针，这些Bug在数据库这种长期运行的程序里，可能潜伏几年，然后在某个高负载的凌晨三点突然引爆，导致数据损坏。
Rust的所有权模型，就像给代码加了个严格的纪律委员。比如一个函数拿到了某块数据的引用，另一个地方的代码想偷偷修改它，这在C语言里编译通过，运行看运气。在Rust里，这种操作在编译阶段就会被直接红牌罚下，你想让程序跑起来，就得按规矩来。
不过，把PostgreSQL从C搬到Rust，不是简单的Ctrl+C和Ctrl+V，再换个文件后缀名。PostgreSQL内部有查询解析器、执行引擎、事务管理器、锁系统、缓存管理、存储引擎、索引结构……这些模块相互依存，就像人体的心肝脾肺肾，换一个器官，得保证整个系统还能协调工作，这比单纯翻译代码要复杂得多。
AI当苦力的新流水线
pgrust最有意思的一点，不是用了Rust，而是它怎么用Rust。项目作者Michael Malis公开提到，他们极大依赖AI辅助开发，用了多个Codex实例并行地修改代码，再通过自动测试来快速验证结果。
这彻底改变了传统大型软件重写的模式。以前这种事情，一个经验丰富的团队，花上好几年时间都搞不定，因为人需要阅读旧代码、理解设计意图、写新代码、测试、修Bug，循环往复成千上万次。
AI加入之后，工程师的角色更像是在设计一个自动化的软件生产工厂。AI负责执行大部分繁琐的代码转换工作，人负责制定方向、设计测试用例、把控架构。这个变化，很像以前手工打造一辆汽车要好几天，后来有了流水线，现在AI又给流水线装上了机械臂，速度更快，但前提是机械臂不能打歪。
当然，问题也随之而来。用AI生成大量代码很容易，但生成正确的代码非常困难。数据库最怕的不是少一个功能，而是多一个隐藏的地雷。普通程序出错，最多重启一下，数据库出一次错，可能影响成千上万个用户的数据。所以pgrust到现在依然十分强调稳定和测试，而不是急着宣称要替代谁。
可以随意折腾的实验田
直到今天，pgrust还远没到能在生产环境里用的时候，作者自己也说，它还不兼容现有的PostgreSQL扩展，离稳定还有距离。但这并不妨碍我们讨论它真正的价值所在。
pgrust真正重要的，不是它提供了一个“Rust版的PostgreSQL”，而是它提供了一块绝佳的实验田。未来的数据库，可以在这块田里尝试很多以前在老架构上想都不敢想的事，比如更激进的多线程服务器架构、内置的连接池、更智能的数据统计，或者给JSON查询做专门的优化。
过去几十年，数据库的发展重点是稳定，这没有错。但未来的竞争，可能更多地会转向“可修改性”和“可进化性”。一个数据库如果稳定但没人敢动，它就像一座坚固但死气沉沉的城堡。一个数据库如果既稳定，内部结构又清晰方便改动，它就像一座可以不断升级改造的现代化都市，这是完全不同的两种生命力。
网友反应
关于这个用AI将PostgreSQL重写为Rust的项目，网友们在震惊之余，迅速分成了两个阵营。支持者觉得这是一次激动人心的技术探索，而反对者则认为这更像是一场昂贵的烟花秀，绚烂但短暂。
支持者认为这是一次激动人心的技术奇点
支持者普遍觉得，不管怎么说，能让一个如此庞大的数据库系统通过全部四万六千多项测试，这本身就是个了不起的成就。他们指出，PostgreSQL官方的回归测试套件本身就是几十年生产环境经验的结晶，能通过它，说明这个Rust版本已经捕获了原版绝大多数的“标准行为”。在很多人看来，这已经不是玩具，而是一个货真价实的“候选实现”。
另外，支持者也看到了这个项目背后更深层的意义。他们认为，用Rust重写不仅能解决C语言老大难的内存安全问题，更重要的是，这种干净的重构让代码变得更容易理解和修改。加上AI辅助开发，这让很多过去想都不敢想的底层改动变得可行。他们觉得，与其抱着“祖传代码”不敢动，不如借这个机会，尝试给数据库底层架构带来一些真正的新想法。
反对者则抛出三大“灵魂拷问”
第一批反对者的核心论点是“测试不等于真实”。他们觉得，通过回归测试最多只能证明代码没犯“已知的错误”，但数据库真正的可靠性，是在真实世界的诡异流量、并发高峰和各种极限边缘情况下被“磨”出来的。这种实战经验是任何测试套件都模拟不了的。他们担心，这个Rust版本可能跑得很欢，但一旦放到生产环境，就会被一些从未被预料到的古怪操作一击击垮。
第二批反对者把矛头直接对准了代码的质量和可维护性。有人翻出代码库，看到大量充满 unsafe 的代码，质疑这样写的初衷。更让他们不放心的是项目那庞大到夸张的提交记录，几周内几万次提交，几乎无法进行传统意义上的代码审查。他们指出，一个靠AI在短时间内“堆”出来的代码库，将来出了问题，可能只有AI自己能修，这就像一个没有说明书的高科技炸弹，没人敢接手维护。
最后，也是最务实的质疑，来自对项目长期生命力的担忧。很多声音指出，这样一个依赖于特定AI模型和大量token消耗的庞大代码库，如果项目背后的热情消退或者资源不足，很容易就会变成无人维护的“数字废墟”。毕竟，PostgreSQL的辉煌是建立在几十年稳定的社区贡献和持续维护之上的，而这不是一次性的重写能够替代的。这就像是盖了一座漂亮的大楼，但没人愿意当物业。
原文出处：pgrust项目主页 | GitHub malisper/pgrust