pgvector、Pinecone、Weaviate 与 Qdrant：索引放在哪里，决定了一切

速览

四款向量库，对同一个问题给出四种答案——索引贴着什么，而你又要运维什么来让它待在那里。下表先列基本信息；其下的矩阵呈现各自在真正存在差异的那几条轴上最用力的方向。

快照：2026-06-01。向量库的功能演进很快，请对照最新文档核实。

pgvector — 架构详解

存储与索引模型

pgvector 是一个 Postgres 扩展。你在一张已有的表上加一列 vector(d)，嵌入就和这一行的其他数据放在一起——同一个主键、同一组外键、同一份事务日志。ANN 索引可在两种结构中选其一：HNSW，一张保留在 shared buffers 中的可导航小世界图；或 IVFFlat，把向量聚成若干列表，查询时扫描可配置数量的最近列表。无论哪种，索引文件都是一个普通的 Postgres 关系；备份、副本和按时间点恢复都不需要任何新东西。这与分块与向量搜索入门里讲的那套向量检索机制完全相同，只不过被放在了那个已经权威回答 "这行数据是什么？" 的数据库内部。

查询路径（向量 + 过滤 + 混合）

查询就是普通的 SQL。ORDER BY embedding <=> $1 LIMIT k 走 ANN 索引；标量列上的 WHERE 条件走已有的 B-tree 或 GIN 索引；Postgres 计划器再决定是先过滤、再对幸存者做 ANN，还是先 ANN、再过滤。混合检索则由已有零件组合而成：Postgres 全文检索（tsvector + ts_rank）和持有向量的那一行做联表，秩融合在 SQL 里完成——模式与混合检索与重排序里那套一致，只是写成一条查询，而非两个服务。由于联表目标就是那一行本身，那些既需要向量匹配、又需要业务字段（"标题、正文、作者名、最后更新时间"）的智能体查询，一次往返就能拿到。

运行时让什么变难

两件事。第一，超大规模下的过滤型 ANN 是个已知的尖角——计划器有时会选出一条让 HNSW 索引剪枝失效的路径，达到数十亿向量加上高基数过滤时，你可能不得不用索引提示或分区表来"教"它。第二，写放大：HNSW 索引的构建与增量重建会消耗同一台 Postgres 实例的资源，而这台机器还在为事务负载服务，因此重摄取会和 OLTP 路径抢 I/O 和 CPU。务实做法是当摄取量真的上去时把 pgvector 放到一台只读副本（或一份专用的逻辑复制副本）上，这基本就是你本来就会为任何读重型 Postgres 工作负载安排的运维剧本。

Pinecone — 架构详解

存储与索引模型

Pinecone 是把向量数据库做成服务。你创建一个 index：起个名字，定义维度、距离度量和区域；用 namespace 做租户或集合隔离；通过 HTTPS upsert 形如 { id, values, metadata } 的记录。当前的 serverless 层把热计算与冷的 blob 存储层解耦，因此你付的存储费用与查询吞吐解耦——没有分片要规划、没有副本要预置、没有 HNSW 参数要调。内部索引和 ANN 算法不在契约之中；Pinecone 拥有实现，你以透明度换取"再也不必想它"。

查询路径（向量 + 过滤 + 混合）

查询是一次 HTTPS POST：向量、top-k、可选的 metadata filter、可选的 namespace。元数据过滤在遍历过程中应用，而非事后，所以高基数过滤也大致能拿回正确的 top-k。Pinecone 通过同时接收一个稀疏向量与稠密向量并对分数做融合来支持 sparse-dense hybrid；想要 BM25 式的词法检索，由你自己计算稀疏向量（BM25、SPLADE 或同类），两者一起传入。查询返回 ID、分数以及你在 upsert 时存入的元数据——但完整的业务行数据仍在你的主数据库里，于是智能体接着会向你的 Postgres 或 Mongo 发出第二次查询来丰满结果。

运行时让什么变难

三件事。第一，两份事实来源：每一行写进主数据库的数据，都得被嵌入、upsert，并与 Pinecone 保持一致，于是"陈旧向量"或"缺失向量"成为你过去没有的一类 bug。第二，按定义就是供应商锁定——服务不可自托管，所以最便宜的对冲是给读写加一层干净的抽象。第三，数据边界：向量与其附带的元数据离开了你的基础设施，于是受监管的内容需要企业区域或 BYOC 方案，而 Pinecone 的一次故障就是你检索路径的一次故障。这项服务上手快、运维轻；运维成本是把它当成远端依赖、而非你自己拥有的数据库的那份纪律。

Weaviate — 架构详解

存储与索引模型

Weaviate 是一款开源向量引擎，内置一层 schema。你声明 class，每个 class 有类型化的属性，包括 class 之间的 cross-reference——于是 Article 引用 Author 与 Topic，就像图数据库一样，每个 class 都有自己针对 class 级别嵌入的 HNSW 索引。向量化在服务端通过 module 完成：text2vec-openai、text2vec-cohere、text2vec-transformers，再加 reranker 和一个能在数据库里跑 RAG 的 generative module。这套架构在四者中最接近一个"装在盒子里"的小型 graph RAG 系统——向量与类型化关系合住一处。

查询路径（向量 + 过滤 + 混合）

默认查询语言是 GraphQL。一条 Get { Article(nearVector: …, where: …) { _additional { distance } author { name } } } 一次往返就把向量匹配、分数与被联表的 cross-reference 对象一并拿回。混合检索是一等公民算子：hybrid(query, alpha) 把 BM25 与向量结果按 alpha 参数控制的融合权重混合起来；reranker module 还能在查询时再跑一遍 cross-encoder。多租户按 class 切分——每个租户拿到一份隔离的 HNSW 图，避免租户互相污染召回，代价是要维护更多的图。

运行时让什么变难

schema 演化就是那个尖角。schema 是一份契约——加属性没问题，但更换 vectorizer、修改属性类型或重构 cross-reference，通常意味着一次重新向量化加一次迁移，而这恰恰是 pgvector 靠搭车在应用现有 schema 上让你省下的工。Weaviate 同时是你拓扑里另一个有状态的服务——一个独立的故障域，有自己的备份策略、版本升级与 module 配置。这笔交易很实在：你在数据库里得到 RAG 相关的原语（向量化、重排序、图遍历），但要多运维一个 schema 必须维护得整整齐齐的系统。

Qdrant — 架构详解

存储与索引模型

Qdrant 是一款用 Rust 写的开源向量引擎。数据组织成 collection，每个 collection 有向量维度、距离度量，以及可选的具名多向量槽位（例如一个槽位放稠密嵌入，一个槽位放 ColBERT 式的晚交互向量）。每条记录是一个 point：一个 ID、一个或多个向量，以及一份 payload——任意结构的 JSON，并支持按字段建立 payload 索引，相当于元数据上的倒排索引。主索引仍是 HNSW，但 Qdrant 提供 quantization——scalar、product 或 binary——把内存里的向量体积压缩 4× 到 32×，并用完整向量对幸存者做 rescore，这正是单节点能装下大量 point 的原因。

查询路径（向量 + 过滤 + 混合）

招牌特性是 filter-aware HNSW：图遍历在前进过程中即评估 payload 过滤条件，而不是先做 ANN 检索、再事后丢弃不匹配项。收益是重过滤下的召回率——那种"我在最近的 200 个里没找到 tenant_id=42，抱歉"的事后过滤失败模式，在这里基本不会发生，因为遍历不会把预算浪费在不匹配的邻居上。混合检索通过稀疏向量与稠密向量配合实现（BM25 式的稀疏向量在查询时与稠密向量融合），API 还在普通 search 之外暴露 recommend、batch search、scroll，组合进智能体式检索这种由智能体反复发出有针对性查询的循环里很顺手。

运行时让什么变难

你来自托管（或用 Qdrant Cloud），这意味着你运维另一个有状态的服务，连同它的分片、复制因子、WAL 与快照。quantization 强大却非免费——你要自己选 quantization 级别、rescore 深度和分片数，所以运维开销是"再多一套分布式数据库要运维"，而不是"在你已有的数据库上加个扩展"。payload 模型是 JSON 而非 schema，因此没有 Weaviate 那种类型化 cross-reference 的等价物；关系由应用层自己重建。一句实话：在这套对比里，Qdrant 给你最强的过滤型 ANN 引擎，代价是一个由你自己运维的独立有状态系统。

横向对比

索引相对于主数据所在的位置

这正是功能清单藏起来的那条轴，也是决定哪款向量库能在生产环境下与一个真实智能体过招的那条轴。pgvector 把索引放在与你主数据同一行上，归同一个计划器与事务日志管辖，于是一条 SQL 就能把"最近向量"与"真实业务字段"联起来，无需第二跳。Pinecone 把索引搬进托管云里，运维变得容易，但每次检索都变成跨系统联表：向量在那边、源行在这边，应用要负责把两者维护一致。Weaviate 处境更微妙——它的 schema 层想"成为"事实来源（class、cross-reference、服务端向量化），当应用恰好契合 Weaviate 的形态时令人惊艳，当应用的领域 schema 与 Weaviate 的 schema 开始漂移时则令人疲惫。Qdrant 取最朴素的立场：它就是隔壁的一个向量索引，payload 是不透明的 JSON，联表在应用里完成——但这台引擎正是为这种形态而造，做得很好。

规模下的过滤型 ANN 行为

智能体 RAG 查询几乎从不是"给我无过滤的最近 k 个向量"——它们是"属于该租户、该文档类型、该日期范围内的最近 k 个向量"。pgvector 把策略交给 Postgres 计划器：在中等规模下它能挑出 B-tree 与 HNSW 的正确组合，但在高基数下可能落在一条让 ANN 索引剪枝失效的路径上，修法是索引调优或分区。Pinecone 与 Weaviate 都在遍历时过滤，大体可用；Pinecone 隐藏算法、请你信任它，Weaviate 在每 class 上暴露倒排索引，并在召回比延迟更重要时提供 flat-search 的逃生阀。Qdrant 把 filter-aware ANN 当作设计原点：HNSW 遍历在前进时评估 payload 条件，于是"重过滤下召回坍塌"那种让前三者头疼的失败模式，在 Qdrant 这里按构造就不该出现。如果你的智能体过滤又宽又浅，四者都行；如果它窄而精（"只看这位客户最近 30 天的文档，且只看发票类目"），Qdrant 的行为最可预测。

运维与部署故事

四者分得很干净。pgvector 几乎不增加运维面——你已有的 Postgres 备份、副本、监控、RLS，以及云上的托管 Postgres（RDS、Neon、Supabase、Aurora）就覆盖了它，这正是从 pgvector 起步的团队大多就此停下的最大单一理由。Pinecone 把整个运维面交给供应商：无服务器、无分片规划、无 HNSW 调优，代价是检索关键路径上的一项远端依赖和一条独立的账单。Weaviate 是四者中最重的——它本身是一个有状态服务，版本升级、module 配置、schema 迁移都是你应用数据库里没有对应物的工作。Qdrant 比 Weaviate 轻，但仍是一个独立的有状态服务：一份 Rust 二进制可以从一个 Docker 容器扩到一个分片集群，但分片、复制因子、quantization 这些选择都得你来定。一个反直觉的结论：对大多数团队，"应该运维更少的系统还是更能干的系统？"这个问题会自己回答——直到某种查询模式（极大规模、极重过滤、跨区域）真的逼你换成"更能干的那个"为止，"更少的系统"始终领先。

该选哪一个

延伸阅读

本站相关内容：

• 检索增强生成（RAG）详解——向量库托住的那个检索→增强→生成循环，以及为何检索与生成应作为两半来调试。
• 分块与向量搜索直觉——embedding 究竟是什么、最近邻搜索做什么，以及混合检索与重排序如何叠在其上。
• 嵌入：意义即几何——为什么同一份向量在四款向量库之间都能用，以及真正归"模型"（而非索引）所有的是什么。
• 选向量数据库——一份约束优先的选型指南，覆盖 ANN、过滤、新鲜度、混合检索、运维这些产品之间真正不同的轴。
• 混合检索与重排序——为什么单一检索器在结构上不够，以及如何把 BM25、稠密向量与一遍 cross-encoder 组合起来。
• 智能体式检索：把搜索做成工具——当智能体把检索当作可反复调用的工具时，这些向量库实际承托的那个循环。

项目来源：

• pgvector 仓库——扩展本体，含 HNSW 与 IVFFlat 索引文档。
• Pinecone 文档——serverless 索引、namespace、sparse-dense hybrid、metadata filter。
• Weaviate 文档——schema、module、GraphQL 查询 API、混合检索。
• Qdrant 文档——collection、point、payload 索引、filter-aware HNSW、quantization。