pgvector 可能是你启动 RAG 项目最好的选择
用 pgvector 跑 RAG，对独立开发者来说几乎是默认选项。你不需要额外部署服务，PostgreSQL 本身就是成熟的基础设施，加个扩展就能存向量、做相似度检索。启动阶段成本低、运维简单，这个选择没毛病。
但问题来了：数据量涨上去之后，pgvector 的查询延迟会明显变差。很多开发者卡在这个阶段，不确定该不该换、什么时候换、换了能得到什么。这篇文章帮你判断。
4 个信号说明 pgvector 快撑不住了
信号一：向量数量超过百万级，查询延迟开始飘
pgvector 默认使用精确搜索（exact nearest neighbor），向量数据量到百万级别时，一次查询可能要扫几百万条记录。根据 pgvector 官方文档，HNSW 索引能把查询速度提上来，但代价是构建索引慢、内存占用高。如果你开了 HNSW 索引后查询还是在 100ms 以上，说明 pgvector 已经在硬扛了。
对比一下：Qdrant 在百万级向量上做近似最近邻搜索，查询延迟通常在 10-20ms 区间。这个差距在用户体验上是能感知到的。
信号二：你开始需要复杂的过滤条件
RAG 系统不是单纯做向量相似度搜索。你经常需要先按 metadata 过滤（比如”只搜某个文档集合””只搜最近30天的内容”），再做向量检索。pgvector 的过滤是在向量搜索之后执行的，这意味着它先做完完整的向量搜索，再丢弃不符合条件的结果——浪费了大量计算。
Qdrant 和 Weaviate 都支持”先过滤再搜索”（pre-filtering），在大规模数据集上性能差异能达到 10 倍以上。如果你的 RAG 系统有复杂的 metadata 过滤需求，这个差异很致命。
信号三：内存成了瓶颈
pgvector 的 HNSW 索引需要把向量数据加载到内存中才能保证查询速度。100 万条 1536 维的向量（OpenAI text-embedding-3-small 的维度），光向量数据就占大约 6GB 内存。这还不算 PostgreSQL 本身的内存需求。
如果你的数据库实例内存不够，HNSW 索引会被部分换到磁盘上，查询性能直接跳水。专用向量数据库在内存管理上做了针对性优化，Qdrant 支持量化压缩（scalar quantization），能把内存占用压到原来的 1/4 左右，同时保持 99% 以上的召回率。
信号四：你需要多租户或者动态更新
pgvector 的向量索引更新是同步的——每次插入新向量，HNSW 索引都要即时更新。批量插入时性能还行，但如果是高频实时写入（比如用户对话即时入库），索引更新会成为明显的瓶颈。
专用向量数据库普遍支持异步索引构建。Pinecone 和 Qdrant 都可以在后台重建索引，写入和查询互不阻塞。对于多租户场景，Qdrant 的 collection 机制让你为每个租户单独管理向量集合，隔离性比 pgvector 的表级方案好得多。
迁移之前先想清楚一件事
不是所有项目都需要换。如果你的 RAG 系统向量总量在 50 万以下，metadata 过滤逻辑简单，查询延迟在 50ms 以内，pgvector 完全够用。过早引入专用向量数据库只会增加运维复杂度。
判断标准很简单：pgvector 的查询延迟是否已经影响用户体验？如果是，该换。如果不是，别折腾。
迁移路径：从 pgvector 到 Qdrant
如果你决定换，迁移没你想的那么复杂。核心步骤就三步：
- 导出向量数据：从 PostgreSQL 导出向量数组 + metadata，存成 JSON 或者直接用 Qdrant 的 snapshot 功能
- 创建 Qdrant collection：设置向量维度、距离度量（通常用 Cosine）、量化配置
- 切换检索逻辑：把代码里的 SQL 查询换成 Qdrant SDK 调用，搜索接口的输入输出结构基本不变
OpenAI text-embedding-3-small 的向量维度是 1536 维，单次 embedding 调用成本约 $0.02/百万 token（据 OpenAI 官方定价页）。迁移过程中不需要重新生成向量，直接搬运就行。
成本对比
Qdrant 开源版可以自部署，Docker 一行命令就能跑起来。云托管版 Qdrant Cloud 免费层支持 1GB 存储，对小项目来说零成本起步。Pinecone starter 每月 $70 起步，按 pod 计费。
对比 pgvector：你的 PostgreSQL 实例成本不变，但如果因为内存不够要升级实例，每月多花 $20-40 很正常。换 Qdrant 自部署反而可能更便宜。
总结
pgvector 是起步阶段最务实的选择。但当你的数据量、查询复杂度、或者实时性要求超过它的舒适区时，迁移到专用向量数据库是正确的技术决策。关键是看实际性能指标，而不是提前焦虑。
如果你正在纠结该不该换，跑一个简单的基准测试：用你的真实数据量做 100 次查询，记录 P99 延迟。超过 200ms 就该认真考虑迁移了。
