一、发生了什么
2026年7月，GitHub上一个名为 pgrust 的项目引爆了 Hacker News：两位开发者——Michael Malis 和 Jason Seibel——用 Rust 从零重写了 PostgreSQL，跑通了全部 46,066 条回归测试查询，输出结果与原版 PostgreSQL 18.3 逐字节一致。
HN 帖子在 18 小时内收获 570 分和 476 条评论，评论区旗帜鲜明地分裂成两派：一派认为这是数据库基础设施的未来，另一派则认为”通过测试只是最简单的部分”。
这不是一个”能连上就算兼容”的表面项目。pgrust 与 PostgreSQL 18.3 磁盘格式兼容，可以直接从已有的 PostgreSQL 数据目录启动。它通过了 PostgreSQL 的回归测试套件和隔离测试，覆盖了 SQL 解析、查询规划、执行引擎、存储层、MVCC 并发控制等全部核心子系统。
项目源代码约 250,000 行 Rust，包含 7,102 次提交，在 GitHub 上以 AGPL-3.0 协议开源，已获得 716 颗星。
二、这不是又一个”玩具数据库”
要理解 pgrust 为什么在技术圈引起如此大的震动，需要先理解 PostgreSQL 回归测试套件意味着什么。
PostgreSQL 的回归测试不是简单的功能冒烟测试。它是 PostgreSQL 核心团队在过去近四十年中累积的正确性神谕——每修复一个 bug，就增加对应的测试用例。这套测试覆盖了从基本 CRUD 到复杂子查询、窗口函数、CTE、JSON 操作、全文搜索、正则表达式、几何类型等几乎所有 PostgreSQL 功能。
大多数自称”PostgreSQL 兼容”的数据库，做到的是线协议兼容——客户端能用 psql 连上。pgrust 做到的是行为兼容——同样的 SQL 输入产生逐字节相同的输出。
| 对比维度 | 典型 PG 兼容数据库 | pgrust |
|---|---|---|
| 兼容层级 | 线协议兼容 | 行为兼容（逐字节一致） |
| 回归测试通过率 | 未公开或不完全 | 100%（46,066 条） |
| 磁盘格式兼容 | 通常不兼容 | 可直接挂载 PG 18.3 数据目录 |
| 隔离测试 | 通常不支持 | 完全通过 |
| 代码规模 | 各不相同 | ~250,000 行 Rust |
作者 Malis 的背景也增加了项目的可信度。他曾在 Neon（Databricks 以约 10 亿美元收购的无服务器 PostgreSQL 公司）构建过 PB 级 PostgreSQL 系统，在 Heap 运维过包含超过 1PB 数据的 PostgreSQL 集群，写过几十篇 PostgreSQL 内核分析文章。
三、17 个 AI Agent 同时写代码的开发流程
pgrust 最受争议的一点是其开发方式：AI 辅助编程达到了前所未有的强度。
Malis 在博客中详细描述了开发过程。他没有逐行阅读 PostgreSQL 的 C 源码，而是把 Codex（OpenAI 的编程 Agent）指向 PostgreSQL 源码，让它解释每个子系统的工作原理，然后合作构建对应的最小 Rust 实现。
开发时间线：
- 第 1 天（3 小时）：搭建存储层、SQL 解析器、并发控制、查询执行器，能运行真实的 SQL 查询
- 第 2-7 天：性能实验（线程模型基准测试中单查询快 3 倍，Rust 正则引擎比 PG 引擎快 10 倍）、修复并发 bug
- 第 8-14 天：转向多 Agent 模式，同时开发 PL/pgSQL、JSON 支持、数学函数等大型特性
在高峰期，Malis 使用 Conductor 工具同时协调 17 个 Codex Agent，跨 8 个账户（每个 $200/月），并构建了自定义配额跟踪工具。Agent 之间通过 git worktree 隔离工作空间，每完成一个能通过测试的代码切片就立即提交合并到主分支，以最小化合并冲突。
Malis 自己承认，在多 Agent 阶段后他不再阅读大部分生成的代码。他的角色从”程序员”转变为”技术经理”——判断哪些功能 Agent 能一次搞定，哪些需要深入介入。他对此的类比是：之前在 Freshpaint 当 120 人公司的 CEO 时，也不可能读完所有人的代码，关键在于设置护栏和保持可见性。
这段描述是否让你想到某种不安？评论区很多人感受到了。
四、架构赌注：Rust 不是目的，是手段
pgrust 的目标不是造一个 PostgreSQL 的 Rust 克隆。Malis 在《Postgres 宕机的四骑士》一文中系统阐述了 pgrust 想要修复的四大 PostgreSQL 架构问题：
4.1 VACUUM 与事务 ID 回卷
PostgreSQL 使用 32 位事务 ID，最多支持约 40 亿个事务后必须回收。负责回收的 VACUUM 后台进程如果跟不上写入速度，PostgreSQL 会直接关闭整个数据库以防止数据损坏。这在生产环境中造成了成千上万次宕机。
pgrust 的应对方向：
- 采用 64 位事务 ID（上游有一个补丁但长期未被合并，因为会破坏兼容性并增加每行 32 位开销）
- 探索基于 undo log 的无 VACUUM 存储架构（类似 Oracle 的方案）
4.2 连接限制与进程模型
PostgreSQL 使用进程-per-连接模型。每创建一个连接就 fork 一个新进程，代价高昂。这就是为什么每个 PostgreSQL 部署都需要 pgBouncer 之类的外部连接池工具——这是在给架构限制打补丁。
pgrust 从第一天就采用线程-per-连接模型。为什么 PostgreSQL 不用线程？因为在 C 语言中，线程安全很难保证。而 Rust 的所有权模型在编译期就排除了数据竞争。
4.3 糟糕的查询计划
PostgreSQL 的查询优化器在大多数情况下表现良好，但当它出错时——一条通常 10ms 的查询突然跑到 10 分钟——用户几乎没有任何有效的干预手段。PostgreSQL 没有类似 MySQL 的 planner hint 机制。
pgrust 的长远目标：构建自适应查询优化器，在检测到查询计划退化时自动调整。
4.4 JSON 支持
PostgreSQL 不对 JSONB 列收集任何有意义的统计信息。当你在 JSON 字段上做过滤时，PostgreSQL 永远假设匹配 0.1% 的行——一个写死的魔法数字。实际值可能是 80%，也可能是 0.0001%。这意味着一旦开始在 JSON 上过滤，查询计划几乎一定是错的。
pgrust 计划为 JSON 构建真正的统计信息收集，并引入字典压缩来减少 JSON 存储空间。
| 痛点 | PostgreSQL 现状 | pgrust 方案 |
|---|---|---|
| VACUUM / 事务回卷 | 32 位 XID, VACUUM 机制 | 64 位 XID, 探索 undo log |
| 连接模型 | 进程 per 连接 | 线程 per 连接 |
| 查询计划退化 | 无有效干预手段 | 自适应查询优化器 |
| JSON 统计信息 | 固定 0.1% 魔法数字 | 真实统计 + 字典压缩 |
五、社区分裂：支持者与质疑者的交锋
HN 评论区 476 条回复中，争论集中在几个核心问题上。
支持者的论点
- “30 年的 C 代码库几乎不可能进行架构级别的改动”：进程模型切换到线程模型需要重构几乎所有 PostgreSQL 代码。从零开始反而容易。
- “Rust 的安全保证使线程模型成为可能”：PostgreSQL 坚持进程模型很大程度上是因为 C 语言的线程安全隐患。Rust 改变了这个方程。
- “回归测试通过是一个有意义的信号”：46000+ 条查询逐字节一致不是表面功夫。
- “AI 辅助让不可能的变成可能”：两位开发者在几周内完成了一个传统上需要大团队数年的工作。
质疑者的论点
- “2,664 个 unsafe 代码块”：byteiota 的分析指出，pgrust 代码库中有 2,664 个
unsafe {}块和 1,835 个unsafe fn声明。批评者认为大量代码是机械的 C-to-Rust 翻译，并没有真正利用 Rust 的类型安全。 - “通过测试≠生产可靠”：数据库的可靠性来自数十年的生产伤痕。回归测试只能覆盖已经发现的 bug。PostgreSQL 今天优雅处理的每一个边界情况，背后都是某个时刻某人的数据损坏。
- “线程模型的代价”：进程-per-连接虽然代价高，但提供了隔离性——一个 sketchy 扩展崩溃不会带走整个数据库。线程模型下，一个 segfault 可能影响所有连接。虽然 PostgreSQL 在共享内存损坏时本就会杀死所有进程，但进程模型仍然提供了更强的”战斗机会”。
- “性能声明的怀疑”：Malis 在 HN 评论中提到新版本”在 OLTP 上比 PG 快 50%，OLAP 上快 300 倍，只比 ClickHouse 慢 2 倍”。多个评论者对此表示怀疑——“ClickHouse 的人在单个细节上花几百小时优化，这不太可能是真的”。
- “AI 生成代码的可维护性”：如果作者自己都不读大部分生成的代码，谁能维护它？当 AI 模型更新时，代码行为是否会改变？
社区中一个精辟的总结获得了广泛共鸣：“有人看到一个 30 年的系统，想到’过时了’；我看到一个 30 年的系统，想到’久经考验’。“
六、更大的图景：基础设施重写的新范式
抛开 pgrust 项目本身的前途不论，它代表了一个更广泛的趋势信号。
AI 辅助基础设施工程的拐点。两年前，“用 AI 重写 PostgreSQL”听起来像笑话。现在，两个人加 API 费用可以在几周内生成 250,000 行能通过 46,066 条回归测试的数据库代码。这与传统观念——数据库必须由大型团队花数十年打磨——产生了根本性冲突。
Rust 在基础设施中的扩张。从 SWC（替代 Babel）、Turbopack（替代 Webpack）、到现在的 pgrust，Rust 正从应用层工具渗透到最核心的基础设施。PostgreSQL 可能是迄今为止最大的目标。
“可修改性”作为设计目标。pgrust 的核心论点不是”Rust 写的更快”——性能只是副产品。核心论点是：一个用现代语言编写的、结构清晰的代码库，比一个 40 年累积的 C 代码库更容易演进。PostgreSQL 核心团队并非不想改进架构，而是在现有的代码基础上进行大规模重构太过困难。
但”难”不等于”不可能”。PostgreSQL 社区也在推进线程化支持，只是速度更慢、更谨慎。这种谨慎不是劣势——当你的软件管理着全球数十亿用户的数据时，谨慎是必须的。
七、pgrust 明确说了自己不是什么
作者在多个场合反复强调：
- 不是生产就绪的：没有经过性能优化，不适合生产环境
- 不兼容现有扩展：pgvector、TimescaleDB、PostGIS 等目前都不兼容
- 不是 PostgreSQL 的替代品：目前是一个实验平台，用于探索架构改进
项目路线图包括：多线程内核、内置连接池、更好的 JSON 工作负载支持、快速数据库分支（类似 git for DB）、无 VACUUM 存储实验、运行时护栏阻止坏查询和 AI 生成的 SQL。
八、一个开放的结局
pgrust 会成功吗？这取决于”成功”的定义。
如果”成功”意味着取代 PostgreSQL，答案几乎肯定是不会——PostgreSQL 拥有数十年的生态积累、扩展系统、运维工具链和社区信任，这些不是 250,000 行 Rust 代码能替代的。
如果”成功”意味着证明架构可以不同——证明线程模型、64 位 XID、自适应查询优化这些想法在 Postgres 兼容的环境中的确有效——那么 pgrust 已经走在路上了。即使 pgrust 本身最终没有成为生产数据库，它探索的技术方向也可能影响 PostgreSQL 本身的演进，或者催生出新的分支。
如果”成功”意味着展示 AI 辅助编程在系统软件领域的可能性边界，这已经是既成事实。无论你喜欢与否，两个人加 API 费用在几周内写出能通过 PostgreSQL 回归测试的数据库——这在 2025 年之前是不可想象的。
对普通开发者来说，pgrust 最重要的启示或许是：你不需要在”全盘接受”和”全盘否定”之间二选一。你可以欣赏工程成就，同时对其生产可靠性持保留态度。你可以对 Rust 重写感到兴奋，同时承认 C 语言写的 PostgreSQL 已经服务了世界三十年。你可以认可 AI 加速了开发，同时担忧生成代码的可维护性。
这些都是合理的立场。它们不是互相排斥的。
参考链接：
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。