malisper/pgrust

如果你在 Postgres 上跑分析查询，想看看现代引擎能做到什么程度，值得花一个下午在沙箱里试试；但还不到把唯一一份数据交给它的时候。

解决什么问题

团队的数据已经存在 Postgres 里，又想要快速的全表扫描类报表查询。常见做法是把数据导出到 ClickHouse 之类的地方，然后维护两套 schema、两种查询语言和一个同步任务。pgrust 改变的是这一步：启动一个声称兼容 Postgres 线路协议和 SQL 方言的服务器，用现有客户端连过去，把分析型表放进它的列存布局，而不用先导出。目标结果是同一个引擎既能跑事务又能跑分析。

有什么不同

这不是 Postgres 扩展，而是重写实现，对标 Postgres 18.6。README 声称线路协议和 SQL 方言兼容，现有驱动和客户端因此有适配路径；Docker 镜像被描述为官方 postgres 镜像的 drop-in 替代，环境变量、初始化脚本目录和数据卷都对应。内部实现上，作者说新版本每个连接使用线程，而不是 Postgres 的每连接一个进程；配合 pgrcolumnar 表访问方法，在 c8g.4xlarge 上冷跑 ClickBench 分析查询，单条查询最高比 PostgreSQL 快 1,600 倍，对比基准是 PostgreSQL 在同一实例类型上公布的结果。这是作者自己的基准，没有独立复现，而且描述的是列存上的分析查询，不是事务吞吐。

真正的取舍在架构信任上。按连接开线程意味着一个崩溃的扩展可能带整个服务器一起挂，而 Postgres 的进程模型能把它隔离住；7 月发布帖下就有 HN 评论者提了这个担心 评论。扩展也是弱项：目前没有稳定的扩展 ABI，第三方扩展不能开箱即用，不过不少流行扩展是随包提供的。项目对信任问题有正面回应：在 3,400 个用户可见函数中，1,397 个用 Kani 形式化验证了行为与 Postgres 一致，另有 466 个拿 Postgres 做了对比测试 验证清单。这能说明投入，但不等于保证正确。

谁值得试

适合：已经有 Postgres 负载的开发者或数据工程师，想拿同样的查询跑一遍列存表，自己判断速度说法是否成立；或者只想在装任何东西之前先在浏览器里摸一下 Postgres 兼容服务器。浏览器演示是成本最低的入口，v0.4-beta 发布说明介绍了改动。

不适合：今天就需要生产级 Postgres 的人，README 自己就这么写，并推荐直接用 Postgres。依赖某个特定第三方扩展的团队也不适合；以短事务为主、而不是分析扫描为主的负载同样不适合，因为主打的基准是分析场景。

使用条件与边界

二进制按平台区分：Linux 需要 glibc 2.34 及以上（Debian 12、Ubuntu 22.04、RHEL/Rocky 9 及更新版本），macOS 需要 11 及以上，另外还有针对 AMD Zen 3+ 和 Neoverse-V2（如 Graviton4）的调优构建 下载页。每个 tarball 自带 postgres、initdb 和 psql，不需要装 PostgreSQL。所以上手很快，长期边界在兼容性：扩展 ABI 不稳定，PL/Python、PL/Perl、PL/Tcl 尚不支持，依赖这些的负载没法原样迁过来。

更大的边界是数据安全，而不是安装。README 说项目内部已经在用，但明确要求把 Postgres 继续当作不能丢的数据的事实来源，并把测试和可靠性列为当前第一优先级。应当把 pgrust 当作对副本做的读取/分析实验，而不是主库的替代品。

HotRepo 点评

HotRepo 只在 2026-07-11 至 2026-07-13 的日榜上记录到 1,848 至 2,324 stars，2026-10-26 为 5,516；只有四个记录在案的榜单日期，无法据此判断关注度能否持续。仓库创建于 2026-04-20，是个年轻项目。投入时间之前，建议先查 验证清单里你的负载会用到的函数覆盖情况，因为 README 的信任论证建立在这份覆盖之上。