作者接手维护 PostgreSQL 向量搜索扩展 VectorChord 分叉

我正在维护 VectorChord（vchord）的分支——它是 PostgreSQL 生态中最知名的向量搜索扩展之一——以及它的配套扩展 vchord_bm25 和 pg_tokenizer，这些分支都放在 pgsty GitHub 组织下。上游的活跃维护停滞之后，TensorChord 的原作者联系我，问我是否愿意接手，下游的 Immich 社区也表示愿意贡献 bug 报告、测试和补丁。

这不是我第一次出手让某个上游依赖继续存活。去年，我接手了 MinIO 的分支，后来它变成了 Silo，在各类 MinIO 分支中已经获得了稳定的关注度。这一路走来，我还做了 barn——一个轻量级的 Vagrant 替代品，以及 Oink——一个从 Docsy 分支出来的 Hugo 文档主题。它们都是我日常工作流中离不开的工具，也都逐渐吸引了外部用户。看来我已经养成了这个习惯。

vchord 由 TensorChord 团队打造，是 pgvecto.rs 的继任者——一个从零开始的 Rust 实现，用对磁盘友好的 RaBitQ 量化、IVF（vchordrq）和 graph（vchordg）索引来补充并挑战 pgvector。

与 vchord 配套的还有同一组织出品的两个 Rust 扩展：vchord_bm25（接替 pg_bestmatch，在 PostgreSQL 中原生提供 BM25 全文排序）和 pg_tokenizer（用于数据库内的多语言分词）。

在向量搜索领域，vchord 及其前身已经获得了真正的生产级采用。它们最知名的下游用户是 Immich——那个自托管的照片和视频库。

如果你不想跟臃肿的 NAS 操作系统较劲，自托管 Immich 是当今管理个人照片库的最好方式之一——这也是 Pigsty 的应用模板很早就收录它的原因。Immich 的视觉相似度搜索和语义搜索依赖 vchord 提供的向量索引。单从技术角度讲，那是个明智的选择。

在 pgvecto.rs、VectorChord 及其配套仓库中，TensorChord 的 PostgreSQL 项目已经获得了超过 4,500 个 GitHub star——在节奏缓慢、系统级复杂度高的数据库扩展领域，这是一份相当亮眼的成绩。在中国 PostgreSQL 开源生态排行榜上，pgvecto.rs 和 VectorChord 在中国团队发起的 PostgreSQL 开源项目中分别位列第三和第四，仅次于 Pigsty 和阿里云的 PolarDB。

在 TensorChord 近期的人事变动之后，活跃维护停滞了：pg_tokenizer 自 2025 年 9 月起就没有发布过新版本，VectorChord 上游最后一次发布（1.1.1）是在 2026 年 2 月，各仓库的提交活动在 2026 年 4 月下旬之后停止——这些项目已经超过六个月没有实质性维护，VectorChord 更是超过八个月没有发布新版本。

在过去，六到十个月的停顿也许算不上什么紧迫问题。一个成熟底层数据库扩展可以原封不动地放上一段时间，跨越若干小版本更新也照样运行良好。但如今，新的 PostgreSQL 大版本发布、pgrx 框架更新以及自动化漏洞发现都在快得多地推进，一个无人维护的扩展会迅速积累风险。

正如我在《当云上布满窟窿》一文中所写，LLM 已经把持续、大规模的代码审计变得足够廉价，攻击者实际上已经用显微镜取代了放大镜。当没人在家给发现的问题打补丁时，基础软件会老得很难看。无人维护的代码并不"稳定"——它是一扇敞开的门。

所以，当原作者联系我，问我是否愿意接手维护，而下游的 Immich 社区也明确表示愿意在 bug 报告、测试和补丁上提供帮助时，这个决定很直接。这些扩展解决的是真实问题，生产用户群是活跃的，而我一想到要看着一件扎实的工程作品——由中国团队打造、被全球用户依赖——慢慢锈掉，就觉得难以接受。

如果你一年前问我，我大概会说不了。从历史上看，维护底层系统软件是一份艰苦的长期承诺，看不到终点。如今，我已经维护了 Silo 一年，工作流程很熟悉，再接一组扩展带来的边际开销是可以承受的。而对于一个 token 额度有富余、偶尔四处找钉子来用 AI 锤子敲的人来说，一颗真正值得敲的钉子主动送上门来，实在很难拒绝。

决定接手很容易；完成一次干净的交接则用了四个具体步骤：

由于原仓库是公司资产，公司层面的变动使得添加外部维护者、调整组织成员身份或转移仓库所有权都变得不切实际——即便原仓库有数千个 GitHub star。与其陷在行政障碍里，我在 pgsty GitHub 组织下创建了全新的分支。我没有保留 VectorChord 这个统括品牌，而是让每个仓库直接以扩展本身命名：

至于上一代（pgvecto.rs 和 pg_bestmatch），Pigsty 的软件包仓库将继续提供预构建的 RPM 和 DEB 包，用于存档保存和现有用户，而活跃的源码级维护则集中在 vchord、vchord_bm25 和 pg_tokenizer 上。

接下来，我 fork 了原来的技术博客和文档仓库，用 Oink 在 vchord.pgsty.com 搭起了一个双语文档站，并针对新的仓库和发布线做了更新。

仓库和文档脚手架就位后，真正的工程工作开始了。我们用前沿模型的代码审计，结合人工审查和复现测试，审计了全部三个代码库，发现了大约 20–30 个问题，其中包括若干严重 bug 和发布阻断项：

每个问题都必须先复现、再打补丁，并通过回归测试验证，才能发布版本。

现在，三个扩展都已在 pgsty 的管理下发布了首个版本：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）