用 AI 把 Postgres 重写一遍，跑分比 ClickHouse 还快 18.5%——pgrust 想解决什么真实问题

拾光·开源拾遗技术创作者 2026-08-19 306 阅读

如果你用 Postgres，每一次 OOM Kill、每一次长查询拖垮整个实例，都是这个 30 年老代码库里藏着的结构性缺陷。Stripe 前工程师 Malisper 从 2024 年底开始，用 AI 把 Postgres 在 Rust 里重新实现了一遍，起了个名字叫 pgrust。目前 4,574 颗 GitHub Star，8 月初刚发布 v0.2。

这不只是一个「 Rust rewrite」的故事——背后有一条很具体的技术逻辑，也有一个很诚实的生产可用性评估。

它到底做了什么

pgrust 是一个从零开始在 Rust 里重写 Postgres 的项目，不是 Fork，不是绑定层，是逐行对应 C 代码的 Rust 重新实现。目标是兼容 Postgres 18.3，目前已经通过了 Postgres 官方的 全部 46,066 个回归测试用例（包括隔离测试）。

能做到这一点，背后经历了四次失败尝试、烧掉 10 万美元调用 Opus API 才走通——详情可以看作者写的 three dead ends 系列博客。这个过程本身就挺值得读的：他们是怎么用 AI 做代码转换的，什么踩了坑，最后怎么解决的。

性能数据：300 倍分析查询加速怎么来的

v0.2 的核心改进是性能。根据 malisper.me 发布的基准测试（由《PostgreSQL 9.0 High Performance》作者 Greg Smith 独立审核）：

ClickBench（ClickHouse 的分析型基准）：pgrust 内置列式存储 pgrcolumnar，得分比 ClickHouse 快 18.5%，比 PostgreSQL 快 数百倍
sysbench-OLTP 读负载（300GB 规模）：比 Postgres 18.3 吞吐量高 30%
v0.2 相对 v0.1 本身，查询引擎提速 10 倍

加速来源是三个核心改进的组合：

向量化 Push-based 执行器 + JIT 编译：传统 Postgres 是火山模型（pull-based），pgrust 改成 Push-based，配合直接吐机器码的 JIT 编译器，把编译时间从 ~50ms 压到 ~5µs
SIMD + Operator Fusion + Batching： analytical 查询的批量处理，配合自适应的 L1/L2 缓存优化哈希表
Query Scheduler：新的查询调度器，主动对长查询降权，防止单个查询把整个数据库打挂

关于第三个改进，作者专门写过一篇文章 The Four Horsemen Behind Thousands of Postgres Outages——OOM Killer、慢查询、连接耗尽、复制延迟，这四个是真实生产环境里 Postgres 挂掉的主要原因，pgrust 的调度器和内置 OOM Killer 直接冲这两个来的。

如何保证正确性

Rust rewrite 数据库，最怕的不是慢，是「看起来能用但结果不对」。pgrust 在正确性验证上下了不少功夫：

用 AWS 的 Kani model checker 对 3,000 个用户可见 Postgres 函数中的 1,000 个做了形式化验证，发现 12 处行为分歧，其中 4 个是 Postgres 本身的 Bug——这个数字本身就挺有意思的
接入 Antithesis 做模拟测试（这是专门做数据库混沌测试的平台）
大规模差分模糊测试，对比 pgrust 和 Postgres 对同一输入的输出是否一致

当然，作者也坦承：pgrust is not production ready. Do not put data you care about in it. 这是写在 README 第一屏的话，不是谦辞。

适合谁 / 不适合谁

适合：

想研究 Postgres 内部实现的开发者（Rust 代码比 C 代码好读得多）
跑分析型查询为主、愿意用 PreGA 软件的团队（pgrcolumnar 列式存储对 OLAP 场景提升显著）
有 Graviton4 实例的 AWS 用户（JIT 编译器专门针对 neoverse-v2 调优，非 Graviton4 硬件性能差距会较大）

不适合：

需要生产级稳定性的业务（目前连扩展 ABI 都没有，现有 Postgres 扩展全部不可用）
需要 PL/Python、PL/Perl、PL/Tcl 的团队（这些语言扩展尚未移植）
对数据持久性零容忍的场景（v0.2 还在 PreGA）

如何快速跑起来

macOS（Homebrew 安装 Postgres 18 客户端工具）：

brew install postgresql@18
export PATH="$(brew --prefix postgresql@18)/bin:$PATH"

curl -LO https://pgrust.com/downloads/v0.2/pgrust-0.2-macos-arm64
curl -LO https://pgrust.com/downloads/v0.2/pgrust-0.2-macos-arm64.sha256
shasum -a 256 -c pgrust-0.2-macos-arm64.sha256
chmod +x pgrust-0.2-macos-arm64

initdb -D /tmp/pgrust-data --no-locale --encoding UTF8 -U postgres
export PGRUST_PGSHAREDIR="$(brew --prefix postgresql@18)/share/postgresql"
export PGRUST_TZDIR="$PGRUST_PGSHAREDIR/timezone"
ulimit -s 65520
RUST_MIN_STACK=33554432 ./pgrust-0.2-macos-arm64 
  -D /tmp/pgrust-data -k /tmp -p 5432 
  -c listen_addresses= -c io_method=sync -c max_stack_depth=60000

Docker（一行启动）：

docker run -d --name pgrust -e POSTGRES_PASSWORD=secret 
  -p 5432:5432 malisper/pgrust:v0.2
psql -h localhost -p 5432 -U postgres

源码编译（需要 Rust 1.96.0 + RE2）：

cargo build --release --locked --bin postgres
# 二进制在 target/release/postgres

链接

GitHub：https://github.com/malisper/pgrust
官网（含 WebAssembly 在线体验）：https://pgrust.com
博客：https://malisper.me/
Docker Hub：malisper/pgrust:v0.2

这个项目最让我觉得有意思的地方不是性能数字，而是它展示了一条用 AI 做大规模代码重写的可行路径：从 46,066 个测试用例倒推，逐文件对应替换，形式化验证兜底。四次失败才跑通这个流程本身，就是一个值得参考的方法论。如果你在做类似的 Rust 重写项目，pgrust 的 README 值得认真读一遍。

评论区

0 条评论

登录后可评论。