PostgreSQL与pgvector

适合先减少系统数量

已有PostgreSQL能力的团队，可以在托管关系库中保存任务、权限、来源版本、记忆事实与向量，使用关联和事务维护这些对象。pgvector提供向量相似搜索及近似索引，因此初期不必仅因需要embedding就额外引入一个服务。

收益主要是数据合同与运维复用，而不是“所有规模都比专用向量库更快”。业务OLTP、全文查询、向量扫描和HNSW构建会争用资源；大规模更新、VACUUM、索引膨胀、备份和恢复都应进入容量与延迟预算。

过滤和执行计划要实测

pgvector官方说明近似扫描后过滤可能导致结果不足，iterative scans可以继续扫描直到达到条件或上限。共享索引的tenant分布还可能互相影响召回和速度。需要检查实际执行计划，比较不同授权子集下的exact和ANN，不应只运行无过滤demo。

RLS可成为防御层，但必须用真实应用角色验证；表owner、superuser与BYPASSRLS具有特殊行为，连接池复用也不能残留上一用户的session身份。中文全文配置需要单独验证术语与编号，并非默认配置即可满足所有企业语言。

何时保留，何时拆分

若现有库在目标并发与更新负载下满足filtered recall、p95和恢复要求，继续共库通常比增加服务更易维护。若检索资源开始拖累业务事务，或者需要独立向量伸缩、多向量和专用布局，可以把索引迁出，保留权威元数据与事件合同。

验收应同时压入业务写入、索引重建和真实过滤query，观察任务状态查询是否受影响。向量数不是唯一阈值；维度、冷热比例、候选预算、tenant倾斜和维护窗口才决定这个选择是否可持续。