如果把数据库比作一家营业多年的银行，重写它不只是换掉柜台系统：旧账本要能直接打开，每笔业务的结果要一致，原有工具最好也能照常工作。pgrust 想做的正是这件难事——用 Rust 重写 PostgreSQL，同时尽量保留它对外的行为与磁盘数据。
这值得现在关注，因为 PostgreSQL 不只是一套存数据的软件。它还是一个由 SQL、事务、扩展和运维工具组成的庞大生态。若重写版本足够兼容，应用就可能保留熟悉的接口和数据，不必整体搬家。不过，目前所有关键结论都来自项目方 GitHub 仓库，尚无独立复现。
它不是另造一种数据库
pgrust 的目标是兼容 Postgres 18.3。项目选择把真正的 PostgreSQL 测试当作“标准答案”，检查自己的输出是否一致。
这类检查叫回归测试：给两个系统相同输入，再对照预期输出。项目方称，当前仓库中的实现已在超过 46,000 条回归测试查询上匹配 PostgreSQL 的预期结果。这个数字说明它已经覆盖了相当多的可观察行为，但不能直接翻译成“完整兼容”。回归查询没有自动证明并发处理、崩溃恢复、性能和扩展生态也同样可靠。
更深入的一步是磁盘兼容。项目方称，pgrust 可以从现有 Postgres 18.3 数据目录启动。换句话说，它不只模仿 SQL 接口，还试图直接读懂 PostgreSQL 已有的数据布局。这比重新设计一套存储格式更难，因为实现必须严格遵守既有文件与版本规则。
Rust 则是这次重写的工具。它是一种强调内存安全、又不依赖垃圾回收的系统编程语言。项目希望借 Rust 和 AI 辅助编程改造服务器内部结构，同时让外部行为继续保持“Postgres 的样子”。吸引力很清楚：保留旧世界的接口，换掉内部引擎。但成熟数据库积累了大量边角行为，真正困难的也正是这些细节。
“测试全过”离“放心上线”有多远？
项目方还称，一个尚未发布的新版本已经通过 100% 的 Postgres regression suite，并把连接模型从“每个连接一个进程”改为“每个连接一个线程”。前者意味着测试套件中的固定样例全部通过；后者则是服务器内部组织方式的变化。两者都值得继续观察，但尚未发布的版本没有给出可对应的具体提交，外界暂时无法核验。
性能数字更应谨慎看。项目方称该版本在事务工作负载上比 Postgres 快 50%，在分析工作负载上约快 300 倍；同时又称它在 ClickBench 上比 ClickHouse 慢 2 倍。这些比较采用了不同参照对象和可能不同的工作负载，不能合并成一个统一的“快多少”结论。材料也没有披露硬件、数据规模、测试参数或完整结果。公开版本仍被项目方明确标为“尚未进行性能优化”，因此不能把这些数字套到 v0.1 上。
真正的门槛在生态
pgrust 已提供 WebAssembly 在线演示和 Docker 镜像 malisper/pgrust:v0.1，当时的 latest 也指向同一版本。这让人可以较低成本地试用，但“能运行”与“能承载生产业务”仍是两回事。
项目方明确表示，pgrust 尚未达到生产可用状态。现有 PostgreSQL 扩展通常也不能直接使用，PL/Python、PL/Perl、PL/Tcl 等过程语言扩展目前不兼容；只有部分随 PostgreSQL 捆绑的 contrib 模块已经移植。对依赖扩展的用户来说，这不是附属问题，而是兼容性的核心组成部分。
局限与未知
- 超过 46,000 条查询和磁盘兼容性均只有项目方陈述，缺少第三方复现。
- “100% 回归套件”和性能结果属于尚未发布的版本，缺少可核验提交与完整测试条件。
- 回归测试通过不等于生产可用，也不能证明安全性、故障恢复和扩展生态已经兼容。
所以，pgrust 目前最准确的定位不是“Postgres 已被 Rust 替代”，而是一场边界很大胆、证据仍在积累的兼容性实验。它已经跨过了大量固定行为测试，也触及磁盘格式；接下来真正决定价值的，是这些结果能否被独立复现，以及它能否从“输出相同”走到“长期可靠地工作”。