通过批处理、算子融合和 SIMD，将 Postgres 在分析场景下提速 300 倍

原文 ↗ Hacker News 讨论 ↗

一个基于 Rust 的 PostgreSQL 重新实现 pgrust 声称通过批处理执行、算子融合、SIMD 和重新设计的调度器，将分析查询提速高达 300 倍，早期基准显示它在某些工作负载上可与 ClickHouse 竞争甚至更快。评论者对其大量使用 AI 生成代码、这种快速产出的系统级数据库的可靠性与安全性，以及形式化验证和模糊测试是否足以让其投入生产，意见尖锐分化。许可也是争议焦点：一些人认为 AGPL 是防止云巨头在不回馈的情况下获利所必需的，而另一些人则认为这会阻碍企业采用和贡献，于是开始讨论分支、替代许可证或其他方案。

许可、商业模式与采用

  • 讨论的主要焦点是 AGPL 许可证。许多人认为这是一条“不可接受的条件”，尤其是在企业环境中，AGPL 要么被禁止，要么被强烈不鼓励，而且它会阻止向上游核心 Postgres 合并。
  • 支持者认为，AGPL（或类似的传染性许可）如今已成为数据库的标准做法，用来防止云服务商在不回馈贡献的情况下，利用宽松许可的工作获利。
  • 也有人建议采用双重许可（AGPL + 商业许可）并签署合适的贡献协议；还有人担心，最终只有核心公司会从社区工作中获得经济收益。
  • 大家对 AGPL 的具体要求存在困惑和分歧；有人声称普通数据库客户端是安全的，也有人强调 AGPL 在法律上仍未经过充分检验，风险很高。
  • 还有人指出，如果性能提升属实，考虑到在 AI 帮助下成本似乎很低，大厂完全可以自己在宽松条款下重新移植 Postgres。

AI 生成的移植版本与版权问题

  • 仓库的提交历史显示，在一个月里有数千次由 AI 共同署名的提交；一些人称之为“AI slop”或“vibecoded”，并质疑人工审查的深度。
  • 描述的流程是：通过 c2rust 将 C 转为 Rust，然后大量用 LLM 重构并补测试。批评者认为这显然是衍生作品，并且在道义上（即使不一定在法律上）不宜重新许可为 AGPL。
  • 关于 LLM 生成的代码是否具有版权，也存在争论；有人认为许可证问题可能因此变得无关紧要，但这点仍被标注为不明确。

性能声明与基准测试

  • 营销宣称其在分析场景下比 Postgres 快约 300 倍；不少评论者对此持怀疑态度。
  • 批评者指出，演示中禁用了 Postgres 的并行能力，使得对比看起来更差；维护者则表示 300 倍这一数字来自启用并行后的 ClickBench 结果。
  • 据说有一位外部专家审查了 ClickBench 的运行结果，并确认了显著的提速；也有人提醒，这些测试可能只反映了特定的、驻留内存的分析型工作负载，而不是通用的 OLTP 使用场景。
  • 讨论指出，许多工作负载受内存和缓存限制；对于某些分析查询，列式执行和向量化执行确实可以带来非常大的收益。

正确性、可靠性与寿命

  • 项目团队强调正确性：对约 1000 个函数进行了形式化验证，与 Postgres 做了差分模糊测试，并进行了外部合作以做故障测试和验证。
  • 他们报告在 pgrust 中发现了约 100 个 bug，在 Postgres 中发现了约 20 个 bug，其中包括一些微妙的浮点错误。
  • 但许多人仍担心，这样一个年轻、由 AI 生成的系统数据库无法与 Postgres 数十年的实战考验相匹敌；对数据损坏和长期维护的担忧很常见。

架构、特性与使用场景

  • pgrust 作为表访问方法加入了列式存储，还包括自适应规划、带资源限流和工作窃取的新查询调度器，以及一个用于加速数据库克隆的“测试模式”。
  • 它可以被嵌入（包括到 Wasm 中），并可能支持每个测试的临时数据库、通过 WAL 提供只读分析副本，以及更轻量级的部署。
  • 有人把它看作一个有前景的 Postgres 兼容分析引擎；也有人怀疑它不会取代 Postgres，但可以针对特定工作负载与之并存。