pgrust 用 Rust 重写了 PostgreSQL，而且 100% 通过了官方回归测试，这事到底意味着什么？

铁锈·Rust工具链内容创作者 2026-07-13 1 阅读

pgrust 用 Rust 重写了 PostgreSQL，而且 100% 通过了官方回归测试，这事到底意味着什么？

导语

如果你是一个前端工程师，可能觉得 PostgreSQL 的源码离你很远。但 pgrust 这个项目——用 Rust 从零重写 Postgres，并且跑通了全部 46,066 条回归测试——跟你其实有直接关系。它证明了「AI + Rust」这条组合路径，正在刷新我们对「大型 C 代码库重写」这件事的认知。而且这事就发生在 2026 年 7 月，GitHub Trending 榜上连续霸榜三天。

这是谁干的，为什么值得看

先说背景。pgrust 的作者 Michael Malis 不是个普通的开源爱好者。他之前在 Heap 担任数据库团队负责人，管理着 PB 级别的 PostgreSQL 集群，业绩是帮公司省下百万美元级的基础设施开支，同事给了他一个绰号叫”Michael Margins”（利润Margin的谐音梗）。2019 年他出来创立了 Freshpaint，一家 YC S19 孵化的医疗数据合规平台，融资 4700 万美元，团队 120 人。

他写 Postgres 完全不是因为”哇 Rust 好酷想玩玩”，而是真实地在 Postgres C 代码库上痛苦了很多年。

问题：PostgreSQL 的 C 代码库有什么痛点？

PostgreSQL 的核心代码用 C 写了 30 多年，规模在 50 万行以上。它被无数公司用在生产环境，但有两个结构性问题一直解决不了：

1. 内存安全。Postgres 的 CVE 公告里，与内存管理相关的问题隔三差五就会出现。这不是 Postgres 特有的——任何大型 C 项目都绕不开 use-after-free、缓冲区溢出。

2. 维护门槛极高。能深入理解整个 PG 内核的新人越来越少。50 万行 C 代码 + 大量宏定义 + 手动内存管理，学习曲线已经陡峭到劝退大多数开发者。

更现实的问题是：Postgres 有超过 350 个配置参数，Malis 的原话是”只要设错一个 VACUUM 参数，你的数据库就挂了”。你需要外挂 PgBouncer 解决连接风暴，JSONB 上没有统计信息导致查询计划一塌糊涂——这些问题他在 Heap 时代天天面对，但想改 C 代码里的任何架构性问题，代价都高到不值得。

这就引出了他的核心判断：「与其在 C 代码库上修修补补，不如用 Rust 重写一遍——反正后者有 AI 辅助，速度不比维护慢。」

方案：AI + Rust，两周写掉 45 万行

2026 年 4 月，Malis 开始用 OpenAI Codex 启动了这个项目。他从一开始就做了一个关键决策：

> 不走 FFI 渐进式替换路线。 Postgres 的 C 组件耦合太紧，混编 Rust 和 C 的难度极高。他选择直接从零写 Rust 版。

这个过程的时间线非常惊人：

Day 1 — 用 Codex 阅读 Postgres 源码、理解每个子系统原理，然后生成 Rust 版本。3 个多小时后，一个能跑 CREATE TABLE、SELECT/INSERT/UPDATE/DELETE、JOIN、事务的原型就出来了。

Week 1 — 代码量涨到 25 万行，通过了约三分之一的回归测试。同时观察到两个早期信号：Rust 的多线程架构在单查询上比 C 版 快 3 倍（小数据集下）；Rust 的正则引擎比 Postgres 旧版 regex 实现 快 10 倍。

Week 2 — 代码 45 万行，兼容性冲到 67%。这里有一个转折点：Malis 引入了 Conductor 多智能体协调工具，同时跑 10-20 个 Codex agent。他买了 8 个 Codex 账号（每个 $200/月），两周合并了 280 个 PR，各个 agent 分别负责 JSONB、外键、日期函数等独立模块。

之后项目其实经历了一次大的版本迭代——第一版曾归档到 archive/pre-fabled-2026-06-23 分支。但第二版在 7 月正式宣布：100% 通过了 PostgreSQL 18.3 全部 46,066 条回归测试和隔离测试，磁盘兼容，可以从现有 PG 数据目录直接启动。

实测数据：这不是玩具

如果说「回归测试通过」是功能正确性的保证，那性能才是让这个项目真正站住脚的证据。

据项目 README 和一个尚未发布的新版本公布的数据：

|———|———|——–|——|

| 单查询（小数据集，多线程） | baseline | 快 3 倍 | 3x |

| 正则引擎 | 旧版 C 实现 | 快 10 倍 | 10x |

| TPC-C（事务处理） | baseline | 快 50% | 1.5x |

| 分析型负载 | baseline | 快约 300 倍 | 300x |

这里要说明一下：分析负载 300 倍这个数据比较极端，很可能是因为 pgrust 的多线程架构——原版 Postgres 每个连接一个进程，而 Rust 版可以用真正的多线程并发扫描。在分析查询这种 CPU 密集场景下，多线程 + 更优的底层数据结构的优势会放大。

但这个数据还需要独立的第三方复现验证，目前看到的只是项目方自己公布的指标。

代码层面的一次对比

为了让你直观感受差异，这里截取一个 Postgres 内部处理逻辑的简化对比。

传统 C 版本的内存上下文管理（Postgres 的 MemoryContext 系统）：

// PostgreSQL C: 手动管理内存上下文
MemoryContext oldcontext = MemoryContextSwitchTo(newcontext);
// ... 在这里分配的内存属于 newcontext
MemoryContextSwitchTo(oldcontext);
// 记得手动切换回来，否则内存泄漏

Rust 版本的等价实现利用所有权系统：

// pgrust Rust: 作用域自动管理
fn query_execute(ctx: &mut QueryContext) -> Result<Vec<Row>> {
    // 进入自动管理的内存区域
    let _guard = ctx.enter_scope();
    let rows = ctx.fetch_rows()?;
    // 离开作用域，_guard drop 自动释放
    Ok(rows)
}

这不只是语法糖层面的差异——Rust 版本在编译期就能保证不会出现 MemoryContextSwitchTo 忘记切回来的 bug。对于 Postgres 这种数十万行的代码库，这种保证的价值怎么强调都不过分。

这件事对前端工程师的启示

你可能会想：这跟写前端有什么关系？关系不小。

1. AI 辅助重写大型代码库已是可行的路径。 如果你在工作中面对一个遗留 JS/jQuery 项目需要考虑现代化迁移，pgrust 证明了「AI 帮你理解旧代码 → 用新语言重写」这条路线是可跑的。这不仅仅是数据库领域的事。

2. Rust 在基础设施层的地位进一步确认。 从 SWC、Turbopack、Oxc 到 pgrust，Rust 正在各个层面取代 C/C++ 的生态位。前端的构建工具链（Vite、Rspack、Rolldown）底层也大量依赖 Rust。理解 Rust 的能力边界，对前端架构师来说正在从”加分项”变成”必修课”。

3. 「多智能体协作开发」不是概念，是已经量产的方法论。 Malis 用 8 个 Codex 账号并行跑 10-20 个 agent，两周合并 280 个 PR——这套工作流本身的价值不亚于 pgrust 这个项目。如果你在做团队内部的 AI 工具调研，这值得你研究一下 Conductor 的工作模式。

收尾：怎么看待 pgrust

pgrust 目前的状态是：功能正确性已证明，生产性能待验证。

如果你在做技术选型调研，它值得放入 watchlist，但不要现在上线生产。
如果你在考虑 Rust 在基础设施层的应用空间，pgrust 是一个极好的案例，能帮你向团队说明 Rust 的资产和代价。
如果你关注 AI 辅助编程的边界，可以关注 Malis 后续会不会开源 Conductor 这套多 agent 编排工具——那可能会比 pgrust 本身更具影响力。

GitHub 地址：github.com/malisper/pgrust。建议 Star 了先观望，等独立第三方跑完基准测试再说。

评论区

0 条评论

登录后可评论。

pgrust 用 Rust 重写了 PostgreSQL，而且 100% 通过了官方回归测试，这事到底意味着什么？