pgvector 官方变更记录显示，0.8.7 于 2026 年 10 月 1 日发布，修复了 IVFFlat 索引构建中的缓冲区溢出，以及无匹配行时 avg 聚合报错。这个修复值得你评估并安排升级，但不代表现有 PostgreSQL RAG 必须迁移到 Qdrant：如果检索负载没有造成可复现的资源争抢或运维瓶颈，先保留共库架构；只有需要独立扩缩、隔离或专门调优时，再验证拆分方案。(pgvector 官方变更记录)
适合已经用 PostgreSQL 和 pgvector 保存知识库内容与向量、希望减少额外服务的独立开发者和小型研发团队。
如果你正评估企业知识库的检索服务是否应独立部署，本文也提供一套可复测的判断方法。
最后更新于 2026 年 10 月 24 日；版本发布日期与修复范围核对自 PostgreSQL 官方发布公告。
pgvector 0.8.7 向量数据库选择：PostgreSQL 共库还是另部署？
0.8.7 是扩展版本更新，是否拆分数据库则是架构决策，两件事不要混为一谈。PostgreSQL 官方公告将这次缓冲区溢出修复关联到 CVE-2026-103484，并提示该问题可能导致任意代码执行；这说明你应核对实际部署并尽快评估修复，而不是据此推断所有版本、所有数据库或所有工作负载都已受影响。变更记录还列出无匹配行时 avg 聚合的错误修复。
如果你在使用 IVFFlat，尤其是自行构建索引的环境，应将扩展版本、构建过程和相关风险纳入升级核查；如果你的索引方式或业务路径不涉及相应条件，也仍应依据官方公告评估升级，但不要把“可能受影响”扩大成“必然已被利用”。
pgvector 和 Qdrant 的 RAG 取舍落在哪些指标？
先按以下指标比，不要只凭“专用向量数据库应该更快”或“共库肯定更简单”来决定：
- 事务与数据一致性：如果知识文档、权限信息、业务记录和向量需要在同一事务里更新，pgvector 与业务表同处 PostgreSQL，可减少跨服务同步及部分状态不一致风险。pgvector 官方项目说明了其与 PostgreSQL 数据、事务和查询能力的结合方式；这适合希望沿用现有 SQL、权限和维护流程的团队。(pgvector 官方项目文档)
- 资源隔离：共库意味着检索、索引构建与普通业务 SQL 仍会竞争同一套数据库资源。Qdrant 独立部署可以让你单独安排服务资源和维护窗口，但并不会自动消除瓶颈；你还要规划它与应用、PostgreSQL 之间的连接和故障处理。
- 过滤与检索质量：真实检索结果取决于向量维度、过滤条件、索引参数、数据更新方式以及召回要求。仅比较数据库名称或网上不同硬件的跑分，不能证明哪一种适合你的查询。
- 维护责任与安全边界：拆出 Qdrant 后，需要新增服务部署、网络访问控制、身份认证、传输加密、监控、备份及恢复验证。Qdrant 官方安全说明指出，自托管开源部署默认不启用认证和加密；不能把服务“已启动”当成已满足生产安全要求。(Qdrant 官方安全文档)
2026 年 4 月，r/vectordatabase 有用户讨论比较 pgvector 与独立向量服务的架构取舍。那是社区用户讨论，不是受控性能测试，也不能代替你自己的负载验证；它更适合作为需求信号：人们在比较的不只是检索速度，还包括是否已有 PostgreSQL、要不要增加维护组件等因素。(社区讨论)
哪些监控信号足以说明该拆分向量检索？
“检索偶尔变慢”本身不是拆库证据。先把问题定位到向量查询，再确认它与其他数据库负载存在稳定、可复现的冲突。PostgreSQL 的监控文档提供活动、I/O、索引和进度等观测入口；EXPLAIN ANALYZE 可以显示实际执行时间与计划节点，但它会实际执行查询，并且测试结果不能直接外推到规模或数据分布不同的生产负载。可参考 PostgreSQL 监控文档 与 执行计划说明。
可以从以下信号开始：
- 延迟与资源同时恶化：按相同查询集观察检索延迟，并同步记录数据库 CPU、内存、磁盘 I/O、连接与锁等待。只有检索变慢但资源充足时，先检查查询计划、索引和过滤条件，别急着迁移。
- 索引构建干扰在线业务：记录构建期间普通业务 SQL 的延迟变化、I/O 压力和任务耗时。如果相同数据与操作在多个维护窗口都造成不可接受的业务干扰，才有理由评估独立资源池。
- 过滤后的召回不稳定：对照目标过滤条件下的召回结果、查询耗时与索引配置。先确认问题不是索引参数、数据分布或查询写法导致；换成 Qdrant 后，也必须用同一批查询和评估口径复测。
- 团队确实需要独立生命周期：例如向量数据更新和业务表更新节奏明显不同，或检索需要单独扩缩、维护与权限边界。若组织流程仍要求同一事务更新、且没有独立运维能力，拆分可能只是把故障点和排障链路变多。
下面这条 SQL 可帮助你检查单条查询的执行计划。使用前先确认测试环境和查询副作用；EXPLAIN ANALYZE 会执行查询，不要把有写入副作用的语句直接拿到生产环境试跑。
EXPLAIN (ANALYZE, BUFFERS)
SELECT id
FROM knowledge_chunks
ORDER BY embedding <=> '[向量值]'
LIMIT 10;
输出应重点看实际执行时间、扫描节点、缓冲区读写以及过滤后剩余行数，不要只盯着计划里的估算成本。上面的表名、列名和向量值是示意；换成你的真实查询、过滤条件和数据规模，才有比较意义。
0.8.7 修复后，现有数据是否要迁移？
通常不需要因为 pgvector 升级而迁移向量数据。扩展升级与数据库迁移不是同一件事：按 pgvector 的安装方式更新扩展文件后，再确认数据库里的扩展版本；迁移到 Qdrant 则是另一个工程项目，涉及数据导出、导入、应用改造、双写或切换策略，以及回滚验证。官方项目文档给出了查询当前扩展版本和执行扩展更新的方式。
升级前先核对 PostgreSQL 主版本、当前扩展版本、软件包或容器镜像的来源，以及服务提供方允许的扩展升级方式。不要默认操作系统里的扩展文件更新后，数据库内所有实例都会自动切换；也不要把示例命令当作所有托管环境都适用的执行流程。
SELECT extversion
FROM pg_extension
WHERE extname = 'vector';
ALTER EXTENSION vector UPDATE;
查询结果示意：
extversion
-----------
0.8.7
上例中的目标版本是本次更新版本；实际执行前应先确认扩展软件已按当前环境的官方方式安装，并在测试环境验证。升级后运行代表性查询，核对召回、过滤行为、索引使用情况和普通 SQL 表现，再按正式变更流程推进。
用同一批查询验证索引与过滤适配
无论继续使用 pgvector，还是把检索服务交给 Qdrant，都用自己的工作负载做对照，而不是套用环境不同的公开跑分。验证方案至少应固定以下输入：
- 使用同一份代表性数据集，并记录向量维度、元数据字段和更新方式。
- 准备真实查询样本，覆盖常见过滤条件、无结果查询和更新后的检索。
- 使用同一召回评估方法，比较相关结果是否进入预期范围。
- 同时记录查询延迟、数据库及应用资源、索引构建对在线 SQL 的影响。
- 在目标部署环境重复测试，记录数据库版本、扩展或服务版本、索引设置和硬件条件。
功能清单可以帮你确定“能不能做”，但适配性仍要由实际查询和运维边界来验证。
升级与拆分的执行清单
按顺序完成以下检查，再决定保留共库还是迁移：
- [ ] 记录 PostgreSQL 版本、
vector扩展版本、安装来源和数据库实例清单。 - [ ] 对照 pgvector 官方变更记录 与 PostgreSQL 官方发布公告，确认修复内容与当前部署的关系。
- [ ] 确认扩展安装包和数据库版本兼容，并在测试环境演练更新；命令以官方说明和你的部署方式为准。
- [ ] 备份数据库，执行恢复演练；升级后用同一组检索查询验证结果、计划和业务 SQL。
- [ ] 在可复现的负载窗口检查延迟、索引构建影响、内存与 I/O 压力，排除查询和索引设置问题。
- [ ] 只有当独立扩缩、资源隔离或维护边界是明确需求时，才搭建 Qdrant 验证环境，并在接入网络前配置认证、TLS、访问限制、监控和备份。
Qdrant 自托管实例的安全设置需要你主动配置。其官方文档说明，默认状态可能没有认证与传输加密；快照机制的具体覆盖范围与恢复步骤，应按 Qdrant 官方快照文档核对，并通过实际恢复演练验证，不能把有快照功能等同于已有可靠备份。
按本站实际机器条件核对部署边界
如果你准备把 PostgreSQL、RAG 应用与向量索引放到独享服务器上，先按实际产品资料核对资源，不要从硬件规格直接推导查询性能。OSFP Cloud 当前产品资料列出 128GB 或 256GB DDR4-3200 ECC RDIMM，以及 2 × 1TB NVMe；这有助于你盘点数据库、应用、索引和日志各自的内存与磁盘需求，但不构成性能、冗余或备份承诺。可先查看内存与磁盘配置说明，再结合数据增长和备份保留策略自行核算磁盘空间。
Linux 通过 SSH 接入；部署前还要明确谁负责数据库升级、网络访问控制、备份复制及恢复演练。你可以先核对服务器远程接入方式，并将 OSFP Cloud 的产品规格与自己的部署清单逐项比对。数据库与 RAG 服务同机，省下的是额外服务链路，不等于资源隔离；反过来，把向量库拆开，也不会自动带来高可用或数据安全。
先定位瓶颈，再决定要不要增加一套数据库
如果你的 PostgreSQL RAG 尚无可复现的资源争抢，且业务依赖同库事务与 SQL 管理，优先核对并升级 pgvector 0.8.7，保留现有数据路径；若监控和同负载测试证明确有独立扩缩、隔离或调优需求，再进行 Qdrant 迁移评估。记住，修复版本值得及时核查，架构拆分则必须由真实负载证明。
共享云主机或 VPS 适合轻量试验，但邻居负载可能带来资源波动，CPU 资源边界和带宽计费也要逐项核实；你对磁盘布局与系统环境的控制也可能不如整机独享。若 PostgreSQL、知识库索引和应用需要长期运行，并且你希望资源归属与系统部署边界更明确，OSFP Cloud 的 AMD 独享物理服务器可以作为候选；先按本站当前产品资料确认可用配置，再依据前面的清单核对负载与运维责任，而不是为一次扩展更新仓促迁库。