基础设施

三年前做一个带检索的 AI 功能,默认动作是去注册一个 Pinecone,或者在 k8s 上拉起一套 Milvus。“做向量检索就得有向量数据库”,这是当时的常识。 2026 年我不会这么干了。我现在的默认动作是反问一句:你的业务数据是不是已经在 Postgres 里了? 如果是,那大概率你不需要再多一个数据库——装个 pgvector 扩展就够了。 这不是图省事。这两年向量检索这个领域发生了一件挺反常识的事:专用向量数据库的护城河,被"在已有数据库里加一个向量列"这件事填掉了一大半。 这篇就讲清楚这件事是怎么发生的,以及——什么场景下你还是真的需要一个专用的。 向量检索这两年变了什么 先说结论:向量检索从"一项需要专门系统的黑科技",退化成了"一种索引类型"。 2022、2023 年的时候,向量检索确实特殊。HNSW 索引怎么建、近似最近邻(ANN)怎么调参、召回率和延迟怎么权衡,这些都是新东西,通用数据库根本不支持。你想做语义检索,除了上专用向量库没有别的选择。专用向量库的价值,很大程度上来自于"别人还做不了"。 到 2026 年,情况倒过来了。HNSW 这种图索引已经是成熟、公开、被反复实现的算法,不再是谁家的秘密。pgvector 作为 Postgres 扩展,把 HNSW 和 IVFFlat 索引、多种距离度量、半精度存储这些都做齐了;0.8 版本之后还补上了"迭代索引扫描"(iterative index scan),专门解决带过滤的向量查询里那个老大难问题——后面会细讲。 换句话说,“做向量检索"这件事本身,已经不构成开一个新数据库的理由了。 它现在更像是"我需要一个 JSON 字段"或者"我需要全文检索”——你的现有数据库基本都能干,只是早几年还不行。 专用向量库不是没价值了,而是价值的位置变了:它不再赢在"能不能做",而是赢在"做到什么规模、做得多快、过滤多复杂"。这是一个量变到质变的边界问题,而不是一个有无问题。 pgvector 为什么吃掉了大半场景 把向量检索塞进 Postgres,带来的好处不是"少装一个软件"这么肤浅。真正值钱的是下面三件事。 第一,数据不用搬,事务是一致的。 绝大多数 AI 功能不是孤立的——一段文档的 embedding,总是挂在某个用户、某个项目、某个权限边界下面。如果向量在专用库、业务数据在 Postgres,你就得自己维护两套数据的同步:文档删了,向量要跟着删;权限变了,检索结果要跟着变。这套同步逻辑写起来不难,但它是一类永远会出 bug 的胶水代码——双写失败、顺序错乱、补偿任务追不上。向量和业务数据待在同一个 Postgres 事务里,这一整类问题直接不存在。 第二,过滤就是普通的 SQL WHERE。 “找语义相近的文档,但限定这个用户、这个时间段、状态是已发布”——这种带元数据过滤的检索是 RAG 里的常态,几乎没有哪个真实业务是纯粹的全库 ANN。在 pgvector 里,这就是一条 SQL,WHERE 子句和向量排序写在一起,还能直接 JOIN 业务表。在专用向量库里,过滤得靠它自己那套 payload/metadata 过滤机制,表达能力通常比 SQL 弱,跨"表"的关联更是做不了。 ...