pgvector还是Pinecone：多重过滤下先看召回

已有PostgreSQL、查询量又低的团队，通常可以先用pgvector。若搜索经常叠加租户、权限、类别等条件，应先确认过滤后的近邻能否找全，再决定是否迁到Pinecone；未经筛选的查询延迟无法回答这个问题。

向量总数可以帮助安排测试，却不是迁移门槛。真正影响选择的是：在相同召回目标下，两种方案各要花多少查询时间、占用多少数据库资源，以及团队要维护多少额外的数据同步工作。Pinecone接管向量索引的运行，已有PostgreSQL的团队则可以先利用现成的数据库容量。

过滤为何会让pgvector先少找结果

pgvector的HNSW候选记录经过PostgreSQL条件过滤后，合格结果减少

pgvector默认执行精确近邻搜索，可以作为过滤后完整召回的基线；建立HNSW等近似索引后，查询速度与召回率开始相互取舍。pgvector项目文档说明，近似索引先扫描，再应用过滤条件：当条件匹配10%的记录、默认hnsw.ef_search为40时，平均只有约4条扫描结果符合条件。请求更多结果时，查询仍可能很快结束，却交不出足额记录。

结果条数和召回率是两件事。继续扫描或扩大候选范围，可能把返回条数补齐，但仍需与“先过滤、再精确计算距离”的结果相比，才能知道真正最近的合格记录是否遗漏。多租户场景尤其容易放大差异：大租户和小租户在共享索引中的记录占比不同，同一组搜索参数未必对两者都合适。

Pinecone将元数据过滤纳入搜索过程，但足额返回也不代表任何过滤比例下都有相同的近邻质量。Pinecone的产品比较页披露，在一项针对1000万向量、以OpenSearch为对手的过滤查询测试中，Pinecone平均找到了真实前十近邻的98.9%；该页同时说明，尚未公布按过滤选择性划分的完整召回曲线。这个厂商结果可以说明其测试条件下的表现，不能当作Pinecone与pgvector在同一负载上的直接成绩。

先固定召回目标，再比较延迟

一场能支持选型的测试，起点应是同一批向量、同一种距离度量、相同的过滤表达式和返回条数。为每条查询先求出过滤范围内的精确近邻，再记录pgvector与Pinecone实际返回了多少条、找回了哪些近邻。只有两边达到同一召回目标时，延迟和吞吐量才有可比性；少找记录换来的速度不应算作优势。

查询样本要覆盖宽松过滤、严格过滤和常见条件组合，并保留不同规模租户的结果。平均匹配比例可能掩盖小租户的问题：即使总体条件看起来并不苛刻，某些权限组合仍可能只允许搜索很小一部分记录。若业务要求每次返回固定条数，还要同时报告不足额查询的比例，避免只公布成功返回的查询延迟。

pgvector一侧可以逐步提高hnsw.ef_search，并测试hnsw.iterative_scan的严格排序与宽松排序模式；迭代扫描达到hnsw.max_scan_tuples等上限仍会停止。对于经常使用的少数过滤值，部分索引值得比较；过滤值很多时，可考虑分区。若普通列索引先缩小了候选范围，精确距离排序也可能比共享HNSW索引更合适。每改动一种配置，都应重新记录召回、尾部延迟和资源占用，而非只挑最快的一次查询。

索引内存决定延迟能否维持

HNSW不只消耗查询时的内存。构建图索引、持续写入以及扩大搜索范围，都可能与同一PostgreSQL实例上的事务负载争用资源。索引无法保持在缓存中时，冷查询和重复查询的延迟也会分开；因此，容量估算需要包括业务表、索引、数据库缓存和建索引时的内存，而不只是向量原始数据的大小。

VectorChord团队的PostgreSQL扩展测试使用500万条、每条768维的向量；其中一个缓存场景采用32 GiB内存的机器，并将shared_buffers设为24 GiB，分别观察首次与重复查询。它比较的是PostgreSQL扩展，测试环境和对象均不同于Pinecone，因此适合提示内存与缓存条件的重要性，不能提供两种产品的同场延迟结论。

PGConf.DE的PostgreSQL向量检索演示也将HNSW的构建和查询列为对内存敏感的环节，并提到磁盘索引与量化等方向。演示没有给出pgvector对Pinecone的同场测量；若内存成为约束，继续留在PostgreSQL的选择并不限于给现有HNSW索引加机器。半精度索引或量化后的重排可以纳入比较，但都需要重新核对检索质量。

查询量低时，比较新增费用

如果现有PostgreSQL实例有足够余量，低查询量应用使用pgvector可能暂时不用增加独立服务。这个前提一旦改变，账就要重算：为索引升级实例、添加只读副本、延长备份时间，或让建索引影响业务查询，都会形成实际成本。沿用数据库的费用应分别按“现有容量够用”和“必须扩容”两种情形计算。

Pinecone公开价目列出带用量限制的免费Starter、每月20美元固定费用的Builder，以及每月最低用量费用50美元的Standard。套餐费用之外，还要根据所选服务和实际读写、存储用量估算账单；这些价格会变化，预算应以采购时的套餐条件为准。低查询量本身不能证明托管服务更贵，也不能抵消超出免费额度或套餐门槛后的费用。

迁到Pinecone后，业务记录若仍以PostgreSQL为准，团队还需维护向量与元数据的写入、更新和删除路径。权限变更后的同步延迟尤其值得计入运维设计：检索结果对应的业务记录可能已经变更可见范围。托管索引减少的是索引容量规划与运行工作，并不会自动消除两套数据之间的一致性责任。

按规模选择验证路径

以下三个规模是安排测试的工作节点，不是pgvector或Pinecone的容量上限。每一档都应使用真实过滤条件，在相同召回目标下比较延迟和完整成本。

约10万向量：已有PostgreSQL且查询量低时，先比较普通列索引配合精确距离排序的延迟。若精确搜索已经满足要求，引入近似索引和第二套服务都缺少明确收益；若权限组合很多，则要覆盖最严格的条件。
约100万向量：把精确搜索、调参后的pgvector HNSW和Pinecone放在同一组过滤查询中比较。此时重点是HNSW为达到目标召回所需的扫描范围、索引占用，以及它是否开始挤占原有数据库负载。
约1000万向量：除查询结果外，还要计算建索引、持续更新、备份、副本和尾部延迟。若PostgreSQL必须专为向量索引扩容，而Pinecone在实际过滤条件下达到同一召回目标，迁出检索便有更充分的理由；若分区后的现有数据库仍能稳定达标，向量总数本身不足以决定迁移。