核心问题: pgrust 能否作为可信的 Rust 版 Postgres 兼容服务器，同时打开 C 版 Postgres 难以实现的内部改造空间？
RepoDaily 采用评分
RepoDaily 将该项目的采用分评为 85/100（强）：分数来自文章来源、安装路径、生产风险、差异化、许可证清晰度以及 AI/Agent 适配度。
包含 5 个来源、覆盖 4 类来源；如有 RepoDaily 独有模块，会进一步提高证据分。
检测到 5 个工作流步骤、5 个下一步动作，以及 4 个命令/安装信号。
趋势热度为 +518 stars；如内容中有 release、issue 或维护信号，会提高维护可信度。
采纳风险标记为 high，并包含 4 条安全说明与 4 条跳过条件。
3 个机会视角、3 个替代方案，以及 4 个类型化模块支撑差异化判断。
文章中包含许可证来源或许可证表述。
文章正文和元数据中检测到 5 个 AI/Agent 相关信号。
项目概览
pgrust 是 Malisper 创建的 PostgreSQL 18.3 Rust 从零重写项目，当前周期获得 518 颗 star，排名第 3。项目目标行为兼容：匹配超过 46,000 条回归查询的预期输出，并与 Postgres 18.3 磁盘格式兼容，可以从现有数据目录直接启动。一个尚未发布的新版本据称已通过 100% 的 Postgres 回归测试套件，将进程级连接改为线程级连接，事务负载比 Postgres 快 50%，分析负载快约 300 倍。
README 明确声明 pgrust 目前不是生产可用，也未做性能优化。现有 Postgres 扩展和过程语言（PL/Python、PL/Perl、PL/Tcl）尚未普遍兼容。部分 contrib 模块已完成移植。路线图包括多线程内部架构、内置连接池、JSON 密集型负载支持、快速 fork 与 branch 工作流、无 vacuum 存储实验、针对低质量查询和 AI 生成 SQL 的运行时防护，以及减少计划突变的优化。
Docker 镜像被设计为官方 postgres 镜像的直接替代品：支持相同的 POSTGRES_PASSWORD、POSTGRES_USER、POSTGRES_DB、POSTGRES_INITDB_ARGS、POSTGRES_HOST_AUTH_METHOD 和 PGDATA 环境变量，支持 /docker-entrypoint-initdb.d 初始化脚本，暴露 5432 端口，以 SIGINT 为停止信号。服务器和目录引导（initdb）均由 pgrust 二进制文件驱动——这是 initdb.c 的忠实移植——镜像中唯一保留的 C 工具是 psql，来自 PGDG 客户端包。
为什么现在变热
- 目标兼容 PostgreSQL 18.3，匹配 46,000+ 回归查询预期输出，未发布版本据称已通过 100% 回归测试套件。
- 磁盘格式兼容意味着 pgrust 可以从现有 Postgres 18.3 数据目录启动，大幅降低评估门槛。
- 未发布版本报告事务负载比 Postgres 快 50%，分析负载快约 300 倍（在 clickbench 上比 ClickHouse 慢 2 倍）。
- Docker 镜像复制了官方 postgres 镜像的契约——相同环境变量、相同入口点、相同端口——在现有 compose 文件中几乎可以无缝替换。
- 路线图直击 C 代码库难以解决的问题：线程级连接、无 vacuum 设计、AI 生成 SQL 的防护。
解决什么问题
- Postgres 的进程级连接模型每连接内存开销大，内置连接池化困难。
- 修改 C 版 Postgres 代码库难度高，深层架构变更（线程化、存储重设计、计划稳定性）在上游推进缓慢。
- pgrust 的扩展和过程语言兼容性（PL/Python、PL/Perl、PL/Tcl）不完整，限制了直接替换场景。
- 项目明确声明当前公开发布版尚未生产可用，未做性能优化。
工作原理
- pgrust 用 Rust 重写了 PostgreSQL 18.3 服务器二进制文件，使用来自 PGDG 分发的 Postgres 产物（postgres.bki、system_*.sql、system_views.sql、时区数据）进行目录引导和时区解析。
- --initdb 驱动是 initdb.c 的 Rust 忠实移植，Docker 镜像中无需 C 版 initdb。
- 构建通过 cargo build --release --locked --bin postgres 生成单个 postgres 二进制文件，PGRUST_PGSHAREDIR 在构建时被绑定以定位 share 目录。
- 服务器以与 Postgres 18.3 相同的磁盘格式读写数据，可以直接从现有数据目录启动。
- 未发布版本将进程级连接改为线程级连接，项目预期这将降低每连接内存开销并启用进程模型难以实现的内部并行。
如何立即试用 pgrust
最快的途径是 pgrust.com 上的浏览器演示，使用编译为 WebAssembly 的 pgrust 运行。对于本地评估，推荐使用 Docker。固定发布镜像为 malisper/pgrust:v0.1；latest 标签目前指向同一版本。
README 提供的 Docker 运行命令会创建名为 pgrust 的容器（设置 POSTGRES_PASSWORD=secret），循环探测容器内 psql 直到服务器响应，然后进入交互式 psql 会话。镜像内置的 psql 来自 PGDG PostgreSQL 18 客户端包——pgrust 尚未提供自己的 psql 替代品。
从源码构建需要 ICU、OpenSSL、libpq 及平台依赖包。Debian/Ubuntu 上执行：sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18。macOS 上执行：brew install icu4c openssl@3 libpq，并导出 LIBRARY_PATH、PKG_CONFIG_PATH、PATH 环境变量。构建命令为 PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" cargo build --release --locked --bin postgres。
工作区结构与覆盖范围
- Cargo.toml 工作区在 crates/_support/ 下包含数十个 crate，覆盖类型绑定（array、brin、gin、gist、hash、nbtree、spgist）、复制（replication、replication_launcher、replication_slot_2）、JSON 处理（types_json、types_jsonb、types_jsonfuncs、types_jsonpath）。
- 支持基础设施包括 PRNG 移植（pg/prng、pg/prng_seams）、资源使用 seam（rusage、rusage_seams）、trace crate 和 todo_guard crate——暗示移植过程仍跟踪未转换或存根代码路径。
- 内置的 nodetags.h（crates/_support/types/nodes/vendor/nodetags.h）在构建时嵌入，意味着 Rust 构建阶段不需要 PostgreSQL C 源码树——仅需 Rust 工具链和 libicu-dev。
Docker 镜像内部结构
- 三阶段 Dockerfile：阶段 1（rustbuild）使用 rust:1-bookworm 构建 postgres 二进制；阶段 2（pgtools）从 PGDG 包提取 psql、libpq 和 share 目录树；阶段 3（final）组装运行时。
- 最终镜像不含 C postgres 后端和 C initdb——仅有 pgrust postgres 二进制文件加上来自 PGDG 的 psql 和 libpq。
- 环境变量契约与官方 postgres 一致：POSTGRES_PASSWORD、POSTGRES_USER、POSTGRES_DB、POSTGRES_INITDB_ARGS、POSTGRES_HOST_AUTH_METHOD、PGDATA 位于 /var/lib/postgresql/data（VOLUME）、postgres unix 用户（uid 999）、/var/run/postgresql 套接字目录、EXPOSE 5432、STOPSIGNAL SIGINT。
- 入口点和 CMD 与官方镜像一致：ENTRYPOINT ["docker-entrypoint.sh"]、CMD ["postgres"]，使用 gosu 降权。
采纳前需验证的事项
- 确认你的工作负载不依赖 PL/Python、PL/Perl、PL/Tcl 或其他 C 链接扩展——这些尚未普遍兼容。
- 确认你依赖的 contrib 模块已在已移植范围内（README 仅声明部分已移植，未列出具体清单）。
- 注意栈大小要求：从源码运行的说明设置 ulimit -s 65520 和 RUST_MIN_STACK=33554432（32 MB）。
- 在将 pgrust 用于任何接近生产的场景前，先用现有 Postgres 18.3 数据目录的副本验证磁盘格式兼容性。
- 审查 AGPL-3.0 许可证：网络可访问的修改版本触发源码披露义务。
谁适合关注
适合关注
- 从 Postgres 18.3 数据目录副本启动 pgrust，在自有 schema 上验证行为兼容性。
- 通过 pgrust.com 的 WASM 演示或 Docker 镜像进行 Rust 移植版 SQL 表面的实际体验。
- 在引入线程级连接和 clickbench 级分析性能的未发布版本发布后，对分析型负载进行基准测试。
- 将路线图中的无 vacuum 设计、计划稳定性、AI-SQL 防护作为研究或原型探索目标。
可以先跳过
- 生产部署：README 明确声明 pgrust 尚未生产可用。
- 依赖 PL/Python、PL/Perl、PL/Tcl 或未移植 C 扩展的工作负载。
- AGPL-3.0 许可证对网络可访问服务带来合规摩擦的环境。
- 需要 pgrust 自带 psql 的场景——项目尚未提供 psql 替代品。
风险与注意事项
pgrust 是一个雄心勃勃且技术上令人印象深刻的重写项目，但明确处于预生产阶段，缺乏扩展兼容性，且最有吸引力的性能数据来自未发布版本。
- README 明确声明'pgrust 尚未生产可用'和'尚未进行性能优化'。
- PL/Python、PL/Perl、PL/Tcl 及其他 C 链接扩展尚未普遍兼容。
- 100% 回归通过率、线程级连接模型和基准数据（事务快 50%、分析快约 300 倍）均来自未发布版本——公开发布的 v0.1 不包含这些。
- AGPL-3.0 对网络可访问的修改版本施加源码披露义务。
- 工作区包含 todo_guard crate 和大量 _support crate，暗示内部移植工作仍在进行。
- 许可证为 AGPL-3.0，要求网络可访问修改版本的操作者向服务器用户提供修改后的源代码。
- Docker 镜像内置的 psql 和 libpq 来自 PGDG PostgreSQL 18 客户端包——这些组件的安全更新依赖 PGDG 的发布节奏。
- 针对低质量查询和 AI 生成 SQL 的运行时防护列在路线图中，但尚未实现。
- 路线图提及运行时防护，但未说明认证、行级安全或加密功能相对于 Postgres 18.3 的兼容状态。
替代方案比较
| 方案 | 适用场景 | 代价 |
|---|---|---|
PostgreSQL (C) | 当你需要久经验证的生产稳定性、完整的扩展兼容性和数十年积累的运维工具链时。 | 免费（PostgreSQL License） |
ClickHouse | 当分析型负载速度是首要需求——pgrust 未发布版本报告在 clickbench 上比 ClickHouse 慢 2 倍。 | 免费（Apache 2.0） |
Postgres 扩展生态（pg_cron、pgvector、PostGIS 等） | 当你的应用依赖 pgrust 尚未移植的特定 Postgres 扩展时。 | 因扩展而异 |
这个趋势说明了什么
线程级连接的 Postgres 内部架构
pgrust 未发布版本将 Postgres 的进程级连接模型替换为线程级连接。这可能解锁跨连接的共享缓冲池、降低每连接内存开销，并启用进程模型难以实现的内部并行。在 C 版 Postgres 中遇到 shared_buffers 或连接扩展限制的工程师，可以将 pgrust 作为这些架构变更的实验平台。
用连接密集型工作负载运行 pgrust 的 Docker 镜像，对比相同数据目录下 C 版 Postgres 的每连接 RSS 内存。
无 vacuum 存储实验
路线图明确列出包括无 vacuum 设计在内的存储实验。受膨胀、autovacuum 调优或长事务开销困扰的团队可以关注项目在 Discord 和 GitHub issues 上发布的存储实验。
关注 pgrust Discord 和 GitHub issues 中的存储实验分支，对比 vacuum 密集型工作负载上的基准结果。
计划稳定性与 AI-SQL 防护
路线图提出减少计划突变和针对低质量查询及 AI 生成 SQL 的运行时防护。这使 pgrust 成为 AI 代理生成 SQL 且计划退化构成运维风险的环境的候选方案。
功能落地后，在包含不同选择率的 AI 生成查询工作负载上对比 pgrust 与 C 版 Postgres 的计划稳定性。
RepoDaily 判断
pgrust 是开源世界中最具野心的数据库重写之一：用 Rust 移植 PostgreSQL 18.3，通过 46,000+ 回归查询，可从现有数据目录启动，并以 drop-in Docker 镜像发布。其未发布版本——100% 回归通过率、线程级连接架构、接近 clickbench 的分析速度——预示了项目的方向。当前阶段应将其视为研究测试平台和兼容性实验，而非生产数据库。