用 Rust 重写 PostgreSQL：一个 30 年 C 代码库的迁移实验
7月9日，一个叫 pgrust 的项目在 GitHub 上引起了关注。它做的事情很直接：用 Rust 重写 PostgreSQL，而且宣称100% 通过了 PostgreSQL 原有的回归测试。
PostgreSQL 的核心代码用 C 写了三十多年，代码规模在 50 万行以上。用 Rust 重写整个数据库——不是写一个 Rust 客户端库，而是把查询引擎、存储引擎、事务管理器、复制协议全部换掉——这件事听起来像是"有生之年"系列。但 pgrust 做到了跑通全部回归测试，这值得认真看一下。
为什么要用 Rust 重写 Postgres
PostgreSQL 是用 C 写的，这是一个事实。C 给 Postgres 带来了极致的性能和底层控制力，但也带来了两个长期问题。
一是内存安全。PostgreSQL 作为生产数据库，代码审查和测试流程已经非常严格，但 C 代码中的 use-after-free、缓冲区溢出之类的问题仍然会周期性出现。CVEs 列表里 Postgres 的安全公告不少与内存管理相关。这不是 Postgres 独有的问题——任何大型 C 项目都绕不开。
二是维护门槛。PostgreSQL 的核心贡献者圈子相对稳定，但能深入理解全部代码的新人越来越少。一个 50 万行的 C 代码库，加上大量的宏定义和手动内存管理，学习曲线非常陡峭。Rust 的所有权系统虽然也有学习成本，但它至少从语言层面消除了很多 C 中需要靠经验来规避的陷阱。
pgrust 的思路是：把 Postgres 的核心逻辑用 Rust 重写一遍，同时保留 Postgres 的 SQL 语法、客户端协议、工具链兼容性——让用户感觉不到底层换了语言。
100% 回归测试通过意味着什么
这个数据是项目的核心卖点，也是最值得拆解的地方。
PostgreSQL 的回归测试套件非常成熟，经过三十年积累，覆盖了 SQL 语法解析、查询优化、并发控制、数据完整性、复制、分区、JSON、全文搜索等几乎所有功能模块。能全部通过，意味着在功能层面，pgrust 已经实现了 Postgres 的完整语义。
但这里有一个需要关注的区别：回归测试覆盖功能正确性，不覆盖性能特性。一个 Rust 重写版在查询逻辑上能返回和 C 版相同的结果，不代表它在同样的硬件上能达到相同的吞吐量和延迟。
不过换个角度看，pgrust 的策略——以回归测试通过率为验证指标——是务实的。先把功能正确性确定下来，再谈优化。这个顺序比先做性能优化再发现 bug 要合理得多。
重写策略：不是 FFI，是替换
pgrust 选择的是完整重写（full rewrite），而不是在 Rust 中通过 FFI 调用 C 模块。这意味着它需要自己实现 Postgres 的内存管理器、锁机制、进程模型等底层基础设施。
从项目 README 的描述来看，pgrust 利用了 Rust 的异步运行时来处理 I/O 和并发，而不是直接移植 Postgres 传统的进程-per-connection 模型。这是 Rust 版本可以尝试的新方向——不用被 C 版本的历史设计决策限制。
不过这也意味着 pgrust 和上游 Postgres 之间会有一个持续的追赶成本。PostgreSQL 社区每发布一个新版本，pgrust 都需要分析变更、评估影响、做适配。这是一个长期维护工作，不是"写完就完事"。
对开发者和数据库生态的影响
对大部分开发者来说，pgrust 在现阶段的影响是潜在的而不是直接的。一个刚刚通过回归测试的项目，距离生产部署还有巨大的距离——稳定性验证、性能调优、生态工具适配都需要时间。
但它打开了一个值得关注的窗口：如果 Rust 真的能在保持 PostgreSQL 兼容性的同时，降低内存安全相关的风险，数据库基础设施的底层技术选择就会多一个选项。
目前数据库领域用 Rust 的案例在增加：RisingWave、QuestDB 的部分组件、CockroachDB 的底层存储层（etcd/raft 实现）都在不同程度上使用了 Rust。但这些都是"新数据库选用 Rust 实现"。pgrust 走的是另一条路——替换已有数据库的实现语言。
这条路更难。它要面对的不只是技术挑战，还有社区信任——DBA 和生产运维团队凭什么相信一个用新语言重写的数据库和原版一样可靠？
对 Rust 语言本身来说，pgrust 也是一个有价值的压力测试。PostgreSQL 的复杂性——混合了 OLTP 和 OLAP、支持多种索引类型、有复杂的锁和并发模型——是对 Rust 类型系统和异步生态的综合考验。
pgrust 可能不会取代 PostgreSQL。但它正在做的实验——验证 Rust 能否承载一个 30 年积累的系统软件——本身就能回答很多关于 Rust 在基础设施领域适用性的问题。
关于维基框架
维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。
官网：framewiki.com
Gitee：gitee.com/wiki-framework
GitHub：github.com/wiki-framework
示例项目：gitee.com/cdkjframework/framewiki-example
📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）