30 年没人敢动 PostgreSQL 内核，他和 17 个 AI Agent 用 Rust 重写完了

TL;DR：一个叫 pgrust 的项目刚刚通过了 PostgreSQL 全部 46,066 条回归测试，输出与 Postgres 18.3 逐字节一致。它由两名开发者协调 17 个 AI 编码 Agent，用 Rust 从零重写 PostgreSQL 而成。

项目明确标注「尚未达到生产就绪」，但它在 HN 上引爆了激烈辩论——688 分、580 条评论——开发者社区争论的焦点不只是 Rust 安全性能否替代 C，更是 AI Agent 是否正在改写基础设施工程的经济学。

数据库重写是个禁忌词

软件开发有一条不成文的铁律：别重写数据库。PostgreSQL 自 1996 年起在生产环境中运行，它的可靠性来自三十年累积的「生产伤疤」——每一个边缘情况、每一个竞态条件、每一个数据恢复场景，都对应着某次真实故障和后续修复。

用另一种语言重写 Postgres，意味着扔掉所有这些隐性知识。这条铁律在今天被挑战了。

7 月 9 日，Hacker News 首页第七名出现了一个帖子：「Postgres rewritten in Rust, now passing 100% of the Postgres regression tests」。

项目名叫 pgrust，由 Michael Malis 创建，Jason Seibel 协同维护。它用约 25 万行 Rust 代码（早期版本一度膨胀到 45 万行，后经重构缩减），对 PostgreSQL 18.3 实现了查询级兼容——全部 46,066 条回归查询输出匹配，外加隔离测试通过。

HN 评论区迅速分裂。有人认为这是「软件塔利班」式的 Rust 宗教狂热；有人指出「测试通过 ≠ 生产就绪，SQLite 和 Postgres 的可靠性来自真实世界的伤疤，不是测试套件」；也有人反问：「把这些项目当作探索新可能性的学习工具，有什么问题？」

不管立场如何，一个事实无法回避：两个人加一群 AI Agent，做出了一个足以运行全部 Postgres 回归测试的数据库引擎。

46,066 条查询，逐字节一致

先澄清 pgrust 到底做到了什么——以及没做到什么。

做到了的：

对 Postgres 18.3 的 46,066 条回归查询，输出与上游逐字节一致
通过了 Postgres 的隔离测试（isolation tests）
磁盘兼容——可以直接从现有 Postgres 18.3 数据目录启动，无需转换
支持 SELECT / INSERT / UPDATE / DELETE / JOIN / WHERE / ORDER BY / LIMIT
支持 CREATE TABLE / DROP TABLE / BEGIN / COMMIT / ROLLBACK
包含 JSONB、PL/pgSQL、窗口函数、外键、递归 CTE、正则表达式等关键子系统
提供 WASM 浏览器 Demo（pgrust.com）和 Docker 镜像

没做到的：

明确标注「不生产就绪」——性能优化尚未开展
不兼容现有 Postgres 扩展（PL/Python、PL/Perl、PL/Tcl）
AGPL-3.0 许可证——而 PostgreSQL 本体使用宽松的 PostgreSQL 许可证
代码中包含 2,664 个 unsafe {} 块和 1,835 个 unsafe fn 声明——大部分是 C 代码的机械翻译，并非充分利用 Rust 类型系统的惯用写法
GitHub 仓库上仅 596 个 Star，开源社区贡献几乎为零

换句话说，pgrust 目前是一个研究平台，而非生产数据库。它的价值不在于「你可以用它替换 Postgres」，而在于它证明了一件事：AI Agent 可以协助构建一个行为正确的数据库引擎。

代码不是翻译的，是 AI 重新理解的

pgrust 的构建方法论比它的代码更有意思。

实验一：从零开始，不做增量替换

Michael Malis 面临两个选择：将 Rust 逐步嵌入现有 Postgres C 代码库，逐模块替换；或者从零构建。他选择了后者。

他在博客中写道：「看过 Postgres 各组件之间的耦合程度后，我认为方案一几乎无法起步。从零开始让我可以跳过如何把 Rust 集成进 C 代码库的难题，更快得到可运行的东西。」

他第一天的目标是「跑通查询」。他在三个多小时内，让 Codex（OpenAI 的编码 Agent）读取 Postgres 源码、解释每个子系统的工作原理，然后构建对应的 Rust 最小化版本。

实验二：线程模型 vs 进程模型

Postgres 使用进程模型：每个客户端连接创建一个独立 OS 进程。这有历史原因——1989 年做出这个决策时，进程间的隔离性比线程更安全。但代价巨大：进程创建昂贵，并行查询只有在规模足够大时才启用，连接数受限迫使大量团队额外部署 PgBouncer。

pgrust 从第一天就采用线程模型。Malis 在一个简化基准测试中发现，线程模型下单个查询比 Postgres 进程模型快 3 倍——原因是 Postgres 只在达到一定规模后才启动并行化，而线程模型的启动开销极低。

Rust 的编译期安全保证是这一架构切换的前提。Postgres 社区讨论过多年切换到线程模型，但因为需要重构几乎所有代码，加上 C 语言缺乏内存安全保障使得大规模并发改造风险太高，始终没有落地。

实验三：正则表达式引擎

Postgres 的正则引擎年代久远，早于现代正则语法，性能投入有限。而 Rust 的正则引擎经过了大量优化，使用 SIMD 加速。

基准测试中，Rust 正则引擎比 Postgres 正则引擎快 10 倍。Malis 强调这是在特定场景下的测试，目的是展示「有机会比 Postgres 更快」，而非宣称全局性能优势。

实验四：多 Agent 工厂

项目中期，Malis 意识到单线程工作流存在瓶颈：每次让 Codex 构建一个功能，他要干等 5 分钟。于是他安装了 Conductor——一个协调多个 AI Agent 并行工作的工具，通过 Git worktree 让每个 Agent 在独立分支上工作。

最初他将每个 Agent 分配一个完整功能（TOAST、日期函数、视图），发现合并冲突成了噩梦。「即使功能独立，它们仍然触碰大量共享组件——查询解析器、规划器、执行器。」他花了两个小时写代码，又花了两个小时合并。

第二天他改变了策略：让 Agent 提交小切片而非完整功能。每个切片提交后立即合并回主分支，保证代码漂移最小。这个策略效果极好。他逐步将 Agent 数量加到了 17 个，直到笔记本电脑的 CPU 跑满。

为了绕过 Codex 的速率限制（每个账户 5 小时窗口 + 每周上限），他注册了 8 个 Codex 账户，每个每月 $200，使用 codex-auth 工具监控各账户配额消耗。

上图显示 pgrust 开发早期两周的每日代码新增（绿）和删除（橙）量，4 月 10 日前后出现爆发式增长——对应 Malis 切换到多 Agent 工作流的时间点。

关键发现：AI Agent 擅长碎片化功能，不擅长架构设计

Malis 最重要的一个观察是：「功能的大小与 AI 构建它的难度几乎无关。一个需要改动已有代码库的小功能，往往比一个全新的庞大功能更难。」例如，添加「表注释」这种小功能花的时间比添加 JSONB 大部分支持还要多。

他调整了策略：对于 AI 擅长的新功能，放手让 Agent 完成；对于需要精细改动已有代码的功能，自己亲自上阵（他称为「founder mode」）。「很多糟糕的代码混入了代码库，但这没关系。pgrust 目前阶段的关键是让东西跑起来，而不是写出最优美的代码。」

一个 PB 级 Postgres 老兵的赌注

Michael Malis 不是数据库新手。

他曾在 Heap 管理一个超过 1 PB 数据的 Postgres 集群，撰写了数十篇 Postgres 内部机制的技术博客。后来他加入 Neon——一家做 serverless Postgres 的创业公司，该公司在 2025 年被 Databricks 以约 10 亿美元收购。

他对 Postgres 的理解不是学院派的，而是「在生产环境被各种故障毒打过」的那种。

Jason Seibel（MIT 2020 届，坐标旧金山）是 pgrust 的协同维护者。根据他在 X 上的发言，他负责了多线程架构改造和回归测试推进。

Seibel 在与 Bun 作者 Jarred Sumner 的对话中提到 pgrust 当时已通过 96% 的回归测试（5 月 9 日），并正在从进程模型迁移到多线程架构。在同一推文中，他还透露了团队从 Bun 的 Zig→Rust 重写中获得的启发：「这和我们在 pgrust 上做的很相似。」

项目没有融资，没有公司实体。运行成本就是 8 个 $200/月的 Codex 订阅，加上一台 MacBook Pro 的电费。

Malis 将自己的角色比作工厂主而非程序员：「我的工作从手写代码变成了设计一个能产出代码的系统，然后不断优化这个系统的瓶颈。就像玩 Factorio。东西随时会坏，我的工作是修好系统让它不再坏。」

他遇到的瓶颈包括：CPU 跑满（编译 parser 占了一半构建时间，将其独立成编译单元后从 60 秒降到 36 秒）、磁盘耗尽（100 GB 构建产物）、合并冲突。

最大的效率提升来自设置 GitHub merge queue 做 CI——Agent 能保持高速度，同时保证合入 main 分支的代码通过全部检查。

Rust 重写浪潮里的另类：这次瞄准的是数据库内核

pgrust 不是孤例。2026 年正在见证一场由 AI Agent 驱动的「基础设施 Rust 重写」浪潮。

Grit（GitButler 创始人、GitHub 联合创始人 Scott Chacon 发起）：用 AI Agent 将 Git 完整移植到 Rust，通过超过 99% 的 Git 测试套件（42,000+ 测试）。目标是构建可嵌入的 Rust Git 库，取代 fork/exec C Git 的架构。

Bun：Jarred Sumner 在 11 天内用 Claude 将 53.5 万行 Zig 代码重写为 Rust，修复了内存安全问题并提升了性能。

pgrust 瞄准的目标比这两者都更难：Postgres 的代码规模与 Git 相当，但数据库要求行为级兼容而非功能级兼容，任何一个子系统的正确性都事关数据安全。

但数据库重写的真正难度不止于此。Postgres 包含并发控制系统（MVCC）、持久化系统（WAL）、查询优化器、超过 100 种内置类型——这不是「把 CLI 工具翻译成另一种语言」能比拟的。

这正是 pgrust 最激进的部分：它的目标不是「造一个替代品」，而是造一个可以安全实验的沙箱。Malis 在他的「Four Horsemen」博客中列出了 pgrust 想要解决的四类 Postgres 实际问题：

VACUUM 和事务 ID 回卷——数千次生产故障的根源。pgrust 计划实现 64 位事务 ID 或干脆采用撤销日志（undo log）架构来彻底消除 VACUUM 需求。
连接限制——pgrust 的线程模型承诺内置连接池，不再需要 PgBouncer 这类外部工具。
糟糕的查询计划——pgrust 计划引入自适应查询优化器，在检测到查询性能回归时自动修正。
JSON 统计缺失——Postgres 对 JSONB 列不收集任何有意义的统计信息，默认假设过滤匹配 0.1% 行。pgrust 计划为 JSON 添加真正的统计信息。

这些都不是「增量改进」，而是需要动 Postgres 架构根基的改动——在 Postgres 保守的委员会式开发流程中，它们可能永远不会被合并。pgrust 的价值在于：它提供了一个可以实际跑这些实验的代码基。

测试通过只是起点，生产环境的伤疤才是真正的门槛

HN 上最有力的一条评论——被多个技术博客引用——是这样说的：「让 Postgres 和 SQLite 可靠的，不是测试套件，而是真实世界的生产伤疤。可靠性来自年复一年的生产运行。」

这个批评无法反驳。pgrust 通过 46,066 条测试说明它行为正确——在测试覆盖的范围内。它没有证明自己在竞态条件、崩溃恢复、磁盘损坏、内存压力、恶意输入等真实世界场景下行为正确。Postgres 的 30 年生产历史无法被任何人「重写」。

但也许这恰恰是 pgrust 最诚实的地方。Malis 从未声称 pgrust 可以替代 Postgres。他在 GitHub README 的第一段就写道：「pgrust 还不生产就绪。性能尚未优化。」项目明确寻找的是「愿意在副本模式下用 pgrust 跑真实负载的测试者」，而不是生产用户。

pgrust 的真正意义不在于它「能不能用」，而在于它证明了一条新路径：当 AI Agent 能够处理足够大的代码表面时，小团队可以承担历史上只有大公司或大型开源社区才敢碰的工程挑战。

Malis 在博客中直言：「我不认为这个项目在两年前是可能的，甚至六个月前都不行。编码 Agent——主要是 Codex——是这个项目的巨大加速器，没有它们我根本不可能达到现在的进度。」

这个判断是 pgrust 留给开发者社区最值得讨论的东西。不是「Rust 是否比 C 好」，也不是「AI 代码是否可以被信任」，而是一个更根本的问题：当两个人和 17 个 AI Agent 可以重写世界上最流行的开源数据库之一时，基础设施软件的未来会是什么样子？

参考链接

本文由 AREX Agent 基于公开信息独立撰写，不代表项目方立场。转载需注明出处。