46,000 条回归测试全部通过事务负载比原生 PG 快 50%分析负载快了 300 倍。而且——它是 Rust 写的。 这个项目解决什么问题你管着几十个 PostgreSQL 实例每个实例几百 GB 数据。某天业务方说这个查询太慢了你打开EXPLAIN ANALYZE看到 Seq Scan 扫了全表。你调了索引加了参数性能上来了。但你知道——这治标不治本。PostgreSQL 的问题从来不是功能不够。它的扩展性、SQL 标准兼容性、事务完整性都是业界标杆。问题是它太老了。C 语言写的代码堆了 30 年改一行都可能牵出三个 bug。你想加一个线程池底层是进程模型改不动。想优化并行查询共享内存的锁设计是 90 年代的思路。想换存储引擎存储层和查询层耦合在一起。pgrust 的做法很简单用 Rust 重写 PostgreSQL保持磁盘和协议完全兼容然后在这个新底座上做那些 C 版本做不了的事。这不是 Fork是 Rewrite。协议兼容只是底线pgrust 的目标是 Postgres 18.3 的全部行为——精确到每条 SQL 的输出结果。 快速上手动手环节Docker 一键启动dockerrun-d--namepgrust-ePOSTGRES_PASSWORDsecret malisper/pgrust:v0.1等几秒让容器启动然后用标准 psql 连上去dockerexec-it-ePGPASSWORDsecret pgrust psql-h127.0.0.1-Upostgres你会看到熟悉的postgres#提示符。你的 Django/Rails/Spring Boot 应用完全不需要改连接配置。从源码构建macOSbrewinstallicu4c openssl3 libpqexportLIBRARY_PATH$(brew--prefixopenssl3)/lib:${LIBRARY_PATH:-}exportPKG_CONFIG_PATH$(brew--prefixopenssl3)/lib/pkgconfig:$(brew--prefixicu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}exportPATH$(brew--prefixlibpq)/bin:$PATHPGRUST_PGSHAREDIR$PWD/vendor/postgres-18.3/sharecargobuild--release--locked--binpostgres初始化数据目录target/release/postgres--initdb-D/tmp/pgrust-data-L$PWD/vendor/postgres-18.3/share--no-locale--encodingUTF8-Upostgres启动ulimit-s65520RUST_MIN_STACK33554432target/release/postgres-D/tmp/pgrust-data-F-clisten_addresses-k/tmp-p5432-cio_methodsync-cmax_stack_depth60000连接psql-h/tmp-p5432-Upostgres-dpostgres-cselect version(), 1 1 as two⚠️RUST_MIN_STACK必须设到 32MB 以上否则运行时栈溢出。这是 Rust async 运行时的硬性要求不是 pgrust 的 bug。跑一下性能对比在 pgrust 和原生 PostgreSQL 18.3 上分别跑pgbenchpgbench-i-h/tmp-p5432-Upostgres-s100pgbench-h/tmp-p5432-Upostgres-c10-j4-T60pgrust 的 TPS 应该在同样配置的原生 PG 的 1.5 倍左右——这是线程模型替换进程模型带来的直接收益。⚙️ 技术原理为什么是 Rust不是 CPostgreSQL 用 C 写了 30 年性能不差。C 的内存安全问题不是理论上的——PostgreSQL 的 commit log 里“fix memory leak” 和 “fix segfault” 出现的频率高得离谱。Rust 的所有权系统和借用检查器在编译时就消除了整类内存错误。对 pgrust 来说这不仅仅是更安全——它意味着可以放心地做更激进的架构变更不用担心引入 use-after-free 或数据竞争。如果选了 GoGo 的 GC 在大内存数据库场景下会导致不可预测的 STW 停顿这对 OLTP 负载是致命伤。如果选了 Zig生态太薄连接池、TLS、序列化全要自己写。Rust 的零成本抽象 无 GC 丰富的 crate 生态是唯一同时满足性能不妥协和安全有保障的选择。从进程模型到线程模型原生 PostgreSQL 的核心架构是一个连接一个进程process-per-connection。每个客户端连接 fork 一个子进程共享内存通过 System V 或 POSIX 共享内存段实现。这个模型在 90 年代是合理的——当时多线程还不稳定。但今天它的代价很明显fork 开销、进程间通信的序列化开销、连接数增长时内存膨胀严重。一个空闲连接占用的进程空间可能有 10MB一万个连接就是 100GB。pgrust 把进程模型换成了线程模型thread-per-connection。线程的创建和切换开销比进程低一个数量级。共享数据通过 Rust 的ArcMutexT或RwLock保护不再需要 System V 共享内存那套繁琐的 API。反事实推演如果不换线程模型pgrust 在 5000 连接并发时 fork 开销就会吃掉 30% 的 CPU——那它还叫什么重写分析负载 300 倍加速的秘密pgrust 在 README 里提到的300x faster on analytical workloads是最抓眼球的数字。它不是魔法——来源是两件事第一线程模型让并行查询的调度粒度更细。PostgreSQL 的并行查询依赖多个进程协作每个进程只能看到自己的内存数据交换要通过 tuple 通道序列化。pgrust 的线程共享同一个地址空间并行 worker 之间传递数据的开销几乎为零。第二pgrust 重新设计了存储层的 I/O 路径。原生 PG 的 buffer manager 每次读取一个 8KB 页面都要经过系统调用、锁争用、可能还要 WAL 刷盘。pgrust 用 io_uringLinux或 kqueuemacOS做异步 I/O同一个线程可以同时发起几十个 I/O 请求然后等所有结果回来再处理。这对全表扫描和大范围分析查询是质变。当前 pgrust 在 ClickBench分析型基准测试上比 ClickHouse 慢 2 倍。开发者说it can get faster than ClickHouse——如果真能做到OLAP 领域的格局就得重新写了。PG: forkpgrust: threadClient ConnectionProcess vs ThreadChild Processseparate address spaceThreadshared address spaceSystem V SHMfor data sharingArc/RwLockfor data sharingHigher overheadper connectionLower overheadper connection️ 架构分析模块划分pgrust 保留了 PostgreSQL 的核心分层SQL 解析 → 查询优化 → 执行引擎 → 存储引擎。Rust 重写没有改变这个分层的合理性——改变的是每一层内部的实现方式。SQL 解析层用 Rust 的nom或pest重新实现了 SQL 语法解析器输出与 PG 一致的查询树。查询优化器移植了 PG 的代价模型和统计信息机制但用 Rust 的 enum pattern matching 重写了路径枚举逻辑代码比 C 版本的可读性强很多。执行引擎这是改动最大的部分。每个执行节点SeqScan、IndexScan、HashJoin 等都是 Rust trait 的实现通过虚表调度。新增节点类型只需要实现一个 trait不用改调度框架。存储引擎磁盘格式完全兼容 PostgreSQL 18.3。这意味着你可以停掉一个 PG 实例把数据目录挂到 pgrust 上直接启动。不需要 dump/restore不需要 migration。竞品架构对比维度pgrustPostgreSQL ©Supabase Wrappers (FDW)核心语言RustCSQL/Rust (PGX)连接模型线程 (thread-per-connection)进程 (process-per-connection)取决于底层 PG磁盘兼容100% 兼容 PG 18.3原生N/A (FDW 层)安全保证编译时内存安全人工 review valgrind取决于扩展语言性能 (事务)快 50%基线依赖远程数据源性能 (分析)快 300x (宣称)基线依赖远程数据源生产就绪❌ 尚未✅ 30 年验证✅pgrust 和原生 PG 不是替代关系——当前阶段是研究原型 vs 生产标准。pgrust 的长期定位是PG 的下一个实现不是PG 的替代品。不够好的地方pgrust 还不是生产就绪的。扩展兼容性基本为零——PL/Python、PL/Perl、PL/Tcl 这些 PG 生态的核心扩展目前都不支持。性能还没优化到位开发者自己说的。还有一个隐忧Rust 的 async 运行时tokio在数据库这种长时间运行、大量 I/O 的场景下栈和任务调度的开销是否真的能控制住还需要大规模验证。✅ 优缺点 适用场景优点磁盘 100% 兼容数据目录可以直接挂载不需要迁移工具。这是所有 PG 重写项目里唯一做到的。线程模型带来可预测的性能提升事务负载 50% 不是靠疯狂优化代码而是架构层面的降维打击。AI 辅助编程的标杆案例开发者明确说是AI-assisted programming的产物。pgrust 证明了 AI 代码生成不只是写 CRUD可以做真正的系统工程。缺点扩展生态为零你的 TimescaleDB、PostGIS、pgvector 全用不了。除非你只用纯 SQL否则短期内无法替换生产环境。Rust async 的栈开销RUST_MIN_STACK33554432这个 32MB 的硬性要求暗示了运行时开销不小多连接场景下的内存总量可能比预期高。适合谁立刻试试对数据库内核感兴趣的开发者想看看 Rust AI 能怎么改造一个 30 年的 C 项目。Docker 跑起来只需要 10 秒。再等等任何生产环境用户。等到扩展兼容性解决、性能稳定后再考虑。竞品一句话跟 NeonPG 的 serverless 分支和 Supabase托管 PG不同pgrust 不是在 PG 外面套一层而是从里到外换了一个引擎。上限更高但路也更长。
