Postgres 被 Rust 重写，而且通过了全部官方测试

导读：有开发者使用Rust重写了PostgreSQL数据库系统，并且运行的良好。

有人用 Rust 重写了 PostgreSQL，并且这个名为pgrust的项目已经通过了全部 46,066 条官方 PostgreSQL 回归查询。它能用普通的 pSQL 客户端连接，支持真实的 SQL、查询计划和存储引擎，甚至可以启动一个已有的 PostgreSQL 18.3 数据目录。

这听起来像是一个可以马上替换生产环境 PostgreSQL 的项目，但请先别急，它显然现在还不是。

真正值得关注的，不只是“Rust 会不会让 Postgres 更快”，而是一个更大的问题：当 AI 编程代理大幅降低重写成本后，我们是否终于有能力重新思考那些已经稳定运行数十年的基础设施架构？

为什么 PostgreSQL 仍然值得被重新思考

PostgreSQL 是有史以来最优秀的数据库之一，这一点没什么好争论的。但它也背负着接近四十年的架构积累，以及约一百万行 C 代码。

其中一个典型设计是每个客户端连接对应一个后端进程。这带来了很强的隔离性，但也意味着：

• 每增加一个连接，就会增加进程和内存开销。
• 高并发应用通常需要依赖连接池。
• 并行任务之间共享状态会更困难。
• 数据库内部组件更难以低成本地协同工作。

这些设计并不是错误。它们在 PostgreSQL 长期演进的过程中解决了大量真实问题，也建立了可靠的故障隔离边界。但旧架构的优势，并不意味着不能探索新的实现路径。

pgrust 到底是什么

pgrust 不是 PostgreSQL 扩展，也不是在原有内核上加一层功能。它是一个独立的 PostgreSQL 实现，目标是保留 PostgreSQL 的行为、客户端体验和磁盘格式，同时把底层数据库引擎改写为 Rust。

换句话说，它想做的不是“一个有点像 Postgres 的数据库”，而是尽可能让外部世界把它当成 Postgres 使用。

当前发布版本以 PostgreSQL 18.3 为兼容目标，重点功能包括如下：

• 支持 PostgreSQL 线协议。
• 支持标准 psql 客户端。
• 支持常规 SQL 操作和查询规划。
• 通过 PostgreSQL 默认回归测试与隔离测试。
• 能够从已有 PostgreSQL 18.3 数据目录启动。

pgrust 的目标不是给 Postgres 加功能，而是用 Rust 重建底层核心，同时保持外部行为兼容。

这种方向和普通扩展完全不同。扩展运行在 PostgreSQL 原有核心之上，天然受限于核心架构。pgrust 则试图把 PostgreSQL 的真实行为当成规范，再用另一套实现去满足这套规范。

它看起来真的像 PostgreSQL 吗？

从实际使用角度看，答案相当接近“是”。使用官方 Docker 镜像启动后，可以直接拿普通 psql 连上去，不需要特制客户端，也不需要学习一套新的查询语言。

连接后，pgrust 会报告自己的版本信息。接下来可以照常创建表、插入数据、执行查询，并使用 EXPLAIN 查看执行计划。查询规划器能够选择索引扫描，也会给出实际执行统计信息。

即使插入 100,000 行数据，再运行查询，外部体验依然很像常规 PostgreSQL：同样的客户端、同样的 SQL、同样形式的结果输出。

标准 SQL、索引扫描和执行统计信息已经可以通过普通 psql 客户端完成验证。

这就是 pgrust 最有分量的地方。它不是只实现了一小部分 SQL 的演示项目，而是一个拥有线协议、查询计划、存储引擎和完整回归测试成绩的真实数据库服务器，只不过它是用 Rust 写的。

为什么不直接写一个 PostgreSQL 扩展或 Fork

一个很自然的问题是：既然 PostgreSQL 已经这么成熟，为什么不直接做扩展，或者 Fork 一份代码来改？

扩展无法替换核心架构

扩展本质上是建立在 PostgreSQL 原始核心之上的能力层。它们可以增加函数、数据类型、索引方式或其他特性，但无法从根本上替换连接模型、进程架构或内部执行方式。

扩展可以增强 PostgreSQL，但它们仍然建立在既有核心架构之上。

Fork 可以改核心，但维护成本极高

Fork 的确可以修改 PostgreSQL 核心，但代价是继承整套旧架构，并长期承担同步上游变更的工作。每一次 PostgreSQL 演进，都可能变成 Fork 维护者需要追赶的分叉点。

CockroachDB 和 Yugabyte 等项目则走了另一条路，它们是独立的分布式数据库。不过，做到与 PostgreSQL 完全可替换的兼容，并不是它们最主要的目标。

pgrust 试图占据一个非常特殊的位置：既不是 PostgreSQL 扩展，也不是传统 Fork，更不是只兼容部分生态的独立数据库。它想要的是一个可替代 PostgreSQL 行为的独立实现。

真正令人期待的架构变化：每连接一个线程

当前发布的 pgrust 版本并没有承诺明显超过 PostgreSQL 的性能。更激进的性能方向，来自一个尚未公开发布的开发版本。

这个版本据称会把 PostgreSQL 的“每连接一个进程”模型，改为每连接一个线程。

进程模型强调隔离，线程模型则可能降低连接开销并加强内部状态共享。

线程模型可能带来的收益

在传统 PostgreSQL 模型中，每个连接运行在独立进程中。新模型则让多个连接线程运行在同一个进程内，这可能带来几个重要变化：

• 降低单个连接的资源开销。
• 减轻对外部连接池的依赖。
• 让数据库内部不同组件更容易共享信息。
• 为并发处理、内建连接池和未来存储实验打开空间。
• 改善某些事务和分析工作负载的执行效率。

进程隔离并非多余的历史包袱。它提供了连接之间的重要安全边界。如果某个进程发生故障，影响范围往往更容易控制。

线程共享同一进程空间，意味着一个不安全的扩展或内存错误，理论上可能影响更多服务器状态。线程模型打开了新的性能和架构空间，同时也可能拿掉某些成熟的安全护栏。

所以，真正的问题不是“进程还是线程哪个绝对更先进”，而是能否在性能、共享能力、故障隔离与生态兼容之间做出可靠的工程取舍。

共享进程可以减少开销，但一个错误也可能拥有更大的影响范围。

AI 编程代理可能才是这次重写最重要的实验

pgrust 由 Michael Malis 和 Jason Seebol 推进，并且在重写过程中大量使用了 AI 编程代理。

公开发布的版本在许多地方仍然有意遵循原始 PostgreSQL 的结构，以便优先验证兼容性。更大胆的架构调整则发生在尚未发布的版本中。

这让 pgrust 的核心问题变成了：

如果 AI 能够把大型重写的成本降到可承受范围，开发者是否可以更频繁地重新审视基础设施的底层架构？

AI 的价值不只是生成代码，更可能是让过去成本过高的基础设施实验变得可尝试。

过去，重写一个拥有数十年历史、百万行代码规模的数据库核心，往往意味着极高的人力成本和极长的验证周期。现在，AI 编程代理或许不能替代工程判断，但可能让探索本身不再遥不可及。

最有价值的地方未必是某个具体的性能倍数，而是开发团队获得了更多实验自由度。不必先重写整个 PostgreSQL 项目，才有资格验证一个新的连接模型或执行思路是否可行。

关于 50% 和 300 倍性能提升，需要保持冷静

尚未公开的线程每连接开发版本，提出了非常大的性能主张：

• 事务型工作负载性能约提升50%
• 分析型工作负载性能最高可达 PostgreSQL 的约300 倍

性能数字很吸引人，但相关实现尚未公开，因此这些结果应被视为有待验证的主张。

这些数字确实巨大，但问题也很直接：产生这些结果的代码目前无法公开检查，也无法由外部独立复现和基准测试。

这不意味着结果一定是错的，只意味着应该把它们当作有前景的声明，而不是已经尘埃落定的事实。尤其是数据库性能高度依赖测试环境、数据集、查询模式、并发设置和系统配置，一个漂亮的倍率远远不足以代表所有现实工作负载。

通过 46,066 条测试，到底意味着什么

通过所有 PostgreSQL 官方回归查询，是一个非常严肃的成就。许多项目都会说自己“兼容 PostgreSQL”，但这个词可以非常宽泛。

pgrust 选择了一个可以衡量的目标：让真实 PostgreSQL 测试集成为裁判。这比泛泛而谈的兼容性更有说服力。

测试通过意味着它已经在大量已知行为上与 PostgreSQL 对齐，包括 SQL 语义、边界条件和许多历史兼容要求。这是让它从概念项目走向真实数据库实现的关键一步。

但测试通过不等于生产可信

回归测试不能替代多年生产运行带来的验证。数据库真正困难的部分，往往出现在最不方便重现的地方：

• 长时间持续运行后的资源和稳定性问题。
• 崩溃恢复与异常断电场景。
• 复制、故障切换和复杂运维流程。
• 极端并发、锁竞争和混合负载。
• 数月甚至数年未曾被专门设计过的边缘条件。
• 第三方扩展、驱动和工具链兼容性。

一个项目可以通过所有已知测试，仍然在没人预料过的场景中失败。生成数十万行代码是一项挑战，让这些代码承受多年真实生产压力是另一项完全不同的挑战。

生态兼容仍是 pgrust 的大缺口

PostgreSQL 的强大从来不只是数据库内核本身，还包括围绕它形成的扩展生态、客户端库、运维工具、迁移流程与长期经验。

pgrust 当前最大的现实限制之一，就是扩展兼容性仍未完成。即使核心 SQL 行为高度兼容，也不代表生产系统依赖的每个扩展、每个插件和每项运维能力都能无缝工作。

这正是“看起来像 PostgreSQL”和“可以替换 PostgreSQL”之间最难跨越的一段距离。

现在应该用 pgrust 替换生产 PostgreSQL 吗？

不应该，绝对不应该。

项目本身已经明确表示，它尚未达到生产就绪状态。当前版本也不是一个完成性能优化的最终产品，扩展生态和重要兼容领域仍在建设中。

但这不代表它不值得尝试。对于从事以下方向的人来说，pgrust 是一个非常有价值的实验对象：

• PostgreSQL 和数据库内核开发。
• Rust 查询执行与存储引擎。
• 数据库兼容性测试。
• 客户端驱动和线协议实现。
• AI 辅助软件重写与基础设施工程。

可以运行它的 Docker 镜像，用自己的客户端库连接它，尝试常见 SQL 工作流，阅读源代码，并观察它在实际测试中的表现。项目仓库位于 GitHub（https://github.com/malisper/pgrust），也可以通过 pgrust.com 进行尝试。

真正值得关注的不是替代，而是可能性

pgrust 现在还不是 PostgreSQL 的生产替代品，但它已经证明了一件很有意思的事：一个完全独立的 Rust 实现，可以在真实 PostgreSQL 测试集、标准客户端和现有数据目录兼容性上走到相当远的位置。

它还提出了两个值得持续追踪的方向。第一个是线程每连接模型能否在不牺牲可靠性的前提下带来真正收益。第二个是 AI 编程代理是否会让大型基础设施重写，从少数公司才能承担的豪赌，变成更多工程团队可以探索的实验。

Rust 重写不会自动让软件更快，AI 生成代码也不会自动让系统更可靠。但当兼容性目标明确、测试足够严格、架构实验可以低成本进行时，许多过去看起来不现实的想法，可能开始变得值得一试。