把 PostgreSQL 那坨积累了 35 年历史的 C 代码用 Rust 从头重写一遍，每隔几年就会有人喊一次这种狂话。2010 年代有过几次尝试，最后都没成气候。所以当我第一次刷到 pgrust 时，本能反应是又一个”兼容 Postgres 协议”的玩具数据库，纯粹标题党。
真正让我停下来多看两眼的是一句话：它能直接挂载你现有的 Postgres 18.3 数据目录启动。这意味着它不只是假装自己像 Postgres，而是磁盘格式、线缆协议、查询结果都和真 Postgres 对齐，行为上就是同一个数据库。再加上 46,066 个官方回归测试百分之百通过，这件事的成色和水兑现不一样了。我当时在想，如果连数据目录都能直接复用，那它和那些只实现协议的兼容层根本不是一回事。
它到底是什么
pgrust 是 Michael Malis（GitHub @malisper）和 Jason Seibel 两个人从 2026 年 4 月开始的副业项目。Malis 不是普通开源爱好者，他在 Heap 管过 PB 级的 Postgres 生产集群，后来当了 Freshpaint 的 CEO，写了多年 Postgres 内核深度的博客。这种”顶级 DBA 加技术管理者”的复合背景，让他能看到别人看不到的改造切入点，也知道哪些痛点真正要命。
它的目标不是做一个”很像 Postgres”的新数据库，而是一套行为对齐、但代码可改的 Rust 内核。路线选得很决绝：从零重写，而不是在 Postgres 的 C 代码里一点点塞 Rust。Malis 的理由很实在，Postgres 各个 C 模块耦合太紧，parser 依赖 catalog，catalog 依赖 storage，你改一个模块其他全得跟着动，用 FFI 保住这种耦合的代价会拖垮整个项目。他宁可在一个干净的架构上重新开始。
Malis 把 Postgres 反复导致的生产事故归纳成”四骑士”：VACUUM 触发的事务 ID 回卷、连接数上限、突然变坏的查询计划、以及 JSONB 缺乏统计信息。这四点都根植于三十年前定下的 C 架构，主线社区想改却改不动。pgrust 从零起步，正是为了把这些”改不动”变成”可以试”，而不是又一个在旧架上修修补补的 fork。
所以它在工程上的真正亮点，不在”重写”这两个字，而在几个更具体的判断，下面逐一说。
打动我的几个地方
第一是回归兼容的含金量。Postgres 的回归测试套件不是玩具基准，它是几十年来每个被修掉的 bug 的”答案卡”。pgrust 现在 46,066 条查询逐字节输出和上游 18.3 一致，还过了事务隔离测试。大多数”兼容 Postgres”的项目只做到线缆协议连通，pgrust 直接过了真实查询回归，这中间的差距对在乎行为正确性的人很关键，因为协议通不代表结果对。
第二是它把一件空想变成了事实：用 Rust 重写成熟基础设施不再是不可能的任务。它已经能 boot 自现有数据目录、用标准 psql 连接、跑从 CREATE TABLE 到 JOIN 再到 PL/pgSQL 的全套操作，行为上和原版无差别，然后才在这个干净底座上做架构实验。这一步顺序很重要，先证明等价，再谈改进，否则改进无从验证。
第三是开发方法本身成了案例。17 个 Codex agent 并行跑，12 周写出约 45 万行 Rust，API 账单每月 1,600 到 2,000 美元。关键不是”让 AI 写代码”，而是 Malis 设计了一套工程纪律：先让 agent 解释某个子系统的 C 源码，再写最小 Rust 等价实现，每次变更立刻跑回归，任何退化当场发现。这种”始终可运行”的约束，才是 AI 速度可信的前提，没有它，17 个 agent 只会制造 45 万行互相矛盾的代码。
第四是那个还没发布的内部版本。作者披露的 early benchmark 里，事务负载比原生 Postgres 快约 50%，分析型查询快约 300 倍，在 ClickBench 上只比 ClickHouse 慢约 2 倍，而他判断还能更快。这里头最值得玩味的是连接模型：用线程替代进程，单进程内共享内存，绕开了 Postgres 几十年的进程隔离包袱，也顺手消灭了 pgbouncer 这种外部补丁的存在理由。
说了这么多亮点，问题来了：真正上手跑起来是什么感觉？我特意走了一遍官方给的两条路径，结论是先从 Docker 开始最省心。
上手什么感觉
最省事的方式是 Docker 一行拉起，然后直接用 psql 连上去，体验和原版 Postgres 没有区别。你不需要下载源码，也不需要编译那 45 万行 Rust，一个镜像就能拿到一个能连的 Postgres 等价内核，适合先验证想法再决定是否深入。
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1
docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres
连上之后，用一条最基础的查询就能确认你面对的确实是 Postgres 等价内核，而不是某个只实现了协议的冒牌货。下面这条语句在 pgrust 和真 Postgres 上会给出完全一致的结果。
select version(), 1 + 1 as two;
README 给的示例输出是 pgrust 18.3 on aarch64-linux-gnu, compiled by clang-21.0.0, 64-bit。我实际没在这台机器上编译，源码构建要装 icu4c、openssl、libpq，还要 vendored 的 PG 18.3 测试文件，macOS 和 Linux 都要先配一堆环境变量。但文档里的命令链路是完整的，跑回归测试也是一条脚本：PGRUST_BIN=... scripts/run-regression，这对想验证兼容性的开发者足够友好。
需要说明，源码构建目前以 Linux 和 macOS 为主，Windows 用户基本只能走 Docker 镜像，这也正好符合它”实验内核”的定位。普通开发者用容器体验完，再决定要不要投入编译那 45 万行 Rust 的时间，节奏更舒服。
不过，能跑起来是一回事，该不该把它放进你的技术选型是另一回事。选型不能只看 demo 顺不顺，得看它在整个生态里站在什么位置。
和谁比，什么时候该看它
如果你已经在用 Postgres，什么时候该考虑换成 pgrust？我的判断很直接：现在不要换生产，它在作者自己的声明里就不是生产就绪的。它的真正对标物不是”要不要替换 Postgres”，而是”Postgres 内核到底能不能被改得更好”，这是一个研究问题，不是替换问题。
横向看，现成的替代路线有三条。第一条是留在上游 Postgres，配合 pgbouncer 补连接池的短板，这是绝大多数公司的现实选择，成熟、稳定、生态全。第二条是 Neon 这类 Postgres fork，它保留了 C 内核、在云上做存储计算分离，本质上还是在 35 年 C 代码的架上修补，换来的是弹性伸缩。第三条才是 pgrust 这种从零 Rust 重写，代价是不能复用现有 C 扩展，但换来了一个真正可改的内核。
| 路线 | 内核语言 | 扩展生态 | 适合谁 |
|---|---|---|---|
| 上游 Postgres | C | 完整 | 绝大多数生产场景 |
| Neon 类 fork | C（云改造） | 完整 | 要弹性算存分离的云用户 |
| pgrust | Rust | 暂缺 | 想改内核、做实验的人 |
所以”适合谁”的答案很清楚：数据库内核开发者想研究 PG 内部却被 C 劝退的，Rust 爱好者，关注 AI 辅助工程上限的技术管理者。普通业务团队现在碰它没意义，等它过了生产验证再说，那时候再评估也不迟。
但选型之外，社区怎么看这件事，往往比作者自己的宣称更诚实。一个项目值不值得长期跟，看 Issue 和 HN 比看 README 靠谱。
社区怎么样了
这个项目在 2026 年 7 月 9 日冲上 Hacker News 首页第一名，807 分、600 多条评论。有意思的是，作者自己的 Show HN 一开始只拿到 6 分，是两周后别人重新提交才引爆的。这个细节说明，项目本身的传播力来自内容，不是来自作者自吹，社区自己认领了这件事。
社区反应明显分成两派：一派觉得这会改变一切，另一派认为”通过测试是最容易的部分”。后者的质疑站得住脚。回归套件覆盖的是已经被发现的 bug，全过只说明没重复已知失败模式，不代表没有从零写出的代码引入的新问题。有评论直接点出：”Database 和 AGPL 是糟糕的组合。”pgrust 用的是 AGPL-3.0，比 Postgres 本身的宽松协议严格得多，网络使用也触发源码披露义务，这对想拿它做 SaaS 的云厂商是个明确的雷。
更刺眼的一个数字是代码库里嵌着 2,664 个 unsafe 代码块和 1,835 个 unsafe fn 声明。这说明大量代码是机械的 C 转 Rust，并不是真正发挥 Rust 类型系统安全性的地道写法。Malis 自己也写过，到某个阶段他”已经不再逐行读大部分代码了”。AI 是加速器，但数据库的可信度是靠几十年生产事故一点点磨出来的，这一点没有捷径，重写也绕不过去。
社区的质疑说了，作者的声明也摆了，剩下的问题是我自己的判断：这个东西到底该不该进你的观察列表。
我的真实看法
值不值得跟？我的判断是：当作研究样本和方法论文献值得跟，当作生产依赖坚决不跟。它最有价值的产出不是数据库本身，而是”用舰队级 AI agent 重写大型遗留系统”这件事第一次有了可验证的工程范式。过去从零重写 30 年 C 代码库要团队加数年，pgrust 把成本压到两个人加几个月加几千美元，这个信号比性能数字更值得数据库圈记住，因为它改变了可行性的边界。
趋势上它在上升：Stars 两个月从 0 涨到约 4.5k，HN 顶部、Docker 镜像、WIP 内部版本的性能宣称都指向活跃。但风险也集中：bus factor 只有两个人，AGPL 把商业云用法挡在门外，扩展生态几乎为零，线程模型的单点故障还没经过实战检验。这些都不是代码能单独解决的问题，是项目治理问题，比跑分更难补。
坑点说在前面：别指望用它跑 pgvector 或 PostGIS，PL/Python、PL/Perl 这些过程语言暂时也不行；别被”快 300 倍”的标题带节奏，那是未发布内部版本的分析负载数字，v0.1 本身作者明确说没做性能优化。把它当成一台能启动、能连、能验证想法的 Postgres 等价内核，预期就对了，别神话也别贬低。
更长远看，pgrust 对 Postgres 主线也可能有反哺价值。线程模型、免 VACUUM 存储、内置连接池这些方向，社区讨论多年却没人实装，因为一个可验证的 Rust 实现反而可能成为推动变革的参照物。它不是来取代 PG 的，是来给 PG 照镜子的，这层意义比它自己能不能商用更持久。
如果你被说动了想去看看，下面这些入口够你起步。clone 之前先想清楚你要的是玩具还是生产依赖，两者预期完全不同。
资源地址
-
仓库：https://github.com/malisper/pgrust -
在线体验（WebAssembly）：https://pgrust.com -
原始发布博客：https://malisper.me/pgrust-rebuilding-postgres-in-rust-with-ai/ -
回归测试里程碑：https://malisper.me/pgrust-passes-100-of-postgresqls-regression-tests -
Discord：https://discord.gg/FZZ4dbdvwU
总结
pgrust 证明的不是”Postgres 能被取代”，而是”Postgres 可以被重新想象”。它用 45 万行 AI 写出的 Rust 告诉我们，重写经典基础设施的门槛已经从”团队数年”降到了”两人数月”。但数据库的可信度要拿真实事故去换，这一点 46,066 个测试过不了，时间也替不了。把它放进你的观察列表，别放进你的生产清单，这个分寸现在就得拿捏清楚。