向量数据库的天花板有多高？

独立向量数据库最尴尬的结局同行还没分出胜负Postgres、Redis、MongoDB、SQL Server 这些老家伙已经上桌夹菜了。几年前做 RAG方案里写 Pinecone、Milvus、Qdrant看着很正常现在不少团队新起检索需求第一反应反而是先上 pgvector或者直接用现有 MongoDB、Redis、Elasticsearch 那套搜索能力撑不住再说。pgvector 没有一夜之间吊打所有专用库。变化发生在另一层存向量、建索引、找 TopK正在从独立卖点变成数据库标配。向量检索本身的天花板还挺高独立“向量数据库”品类的默认购买理由却在变弱。存向量和查 TopK已经不神秘了向量检索核心动作很单纯一段文本变成 embeddingembedding 存起来用户问题也变成 embedding再找距离最近的 K 条。听着像 AI底层其实是老问题近似最近邻搜索ANN早就不新鲜。生产里常见的两条路一条是 HNSW 图索引一条是 DiskANN 这类面向大规模磁盘场景的索引。HNSW 的思路很像在城市里问路不用从每条街挨个走过去先在高速路网里跳到目标附近再往小路里钻。速度快代价是“近似”也就是召回率和延迟之间做交易。DiskANN 系解决另一类问题向量太多内存放不下还想靠 SSD 查得动。Timescale 的pgvectorscale就是把那套思路搬进 Postgres 生态里。单看“最近邻搜索”这层天花板没有想象中玄。后面的进步更多是在召回率多抠几个点、尾延迟少抖一点、同样机器多塞一点向量、索引构建别慢到怀疑人生。重要是重要但更像数据库工程不像一座没人爬上去过的新山。pgvector 最烦的坑在过滤吹 pgvector 的文章最爱说“Postgres 里直接存向量还能和业务表一起查”。话没错但真上线第一个容易咬人的地方就是WHERE。比如一个知识库表长这样selectid,title,contentfromchunkswheretenant_id123anddoc_typecontractorderbyembedding$query_embeddinglimit10;看着很自然。先限定租户和文档类型再按向量相似度排序取前 10。麻烦在于HNSW 这种 ANN 索引和普通 B-tree 两套脾气。pgvector 文档里hnsw.ef_search默认是 40意思是查询时动态候选列表默认就那么大。过滤条件如果很稀疏候选拿回来以后再被tenant_id、doc_type刷掉最后可能凑不够limit 10。一个很粗的心算ef_search 40过滤条件命中 10%平均剩 4 条如果命中 1%平均连 1 条都不到。线上看到的现象很讨厌库里明明有相关内容查询不报错只是返回很少甚至返回空。排查时第一反应会怀疑 embedding、分块、提示词最后才发现是过滤条件把召回打没了。pgvector 0.8.0 之后有iterative_scan可以让它不够就继续往下扫sethnsw.iterative_scanrelaxed_order;sethnsw.ef_search100;hnsw.max_scan_tuples默认 20000文档里也写得很明白它控制 HNSW 最多访问多少 tuple 的近似上限。开了以后结果更稳延迟也会跟着上来。向量检索一旦和元数据过滤搅在一起麻烦就不再是“索引快不快”这么简单了。先过滤还是先向量搜、候选拿多少、过滤选择率多低、错过结果能不能接受全都会变成工程问题。不少专用向量库的卖点恰好也在过滤上Qdrant 专门写过 filterable HNSWRedis 文档里也把带过滤的 KNN 查询单独展开讲。各家文档都在暗示同一个痛点。建索引会在千万级露出脾气小数据量最容易骗人。几十万条 chunk随手CREATE INDEX查询一跑挺快感觉 pgvector 稳得很。到千万级以后麻烦开始冒头。pgvector README 里有一句很实在HNSW 图如果放不进maintenance_work_mem构建会明显变慢还会打出 noticeNOTICE: hnsw graph no longer fits into maintenance_work_mem DETAIL: Building will take significantly more time.那行日志比很多选型 PPT 管用。它说明 HNSW 没法只靠“加个索引”糊弄过去。m默认 16ef_construction默认 64调高能改善召回但构建更慢、写入也更重。maintenance_work_mem、并行 worker、索引重建窗口、线上回滚方案都得开始进入方案。不少团队从 pgvector 往专用库搬触发点往往不在第一天查询慢而是半年后数据涨上去重建索引、调参数、隔离租户、控制尾延迟这些活开始挤在一起。到那时再问“pgvector 能不能用”问法就粗了。更该问当前数据量、过滤条件、写入频率、可用维护窗口Postgres 还能不能扛得舒服。老数据库在把向量检索吃进去独立向量数据库最难受的地方在产品层。底层能力一旦成熟通用数据库就会来收租。SQL Server 2025 文档里已经有vector数据类型、VECTOR_DISTANCE、CREATE VECTOR INDEX、VECTOR_SEARCH。MongoDB Vector Search 可以把向量搜索和全文搜索、字段过滤放在一起。Redis 文档里直接写了 FLAT、HNSW、SVS-VAMANA 这些向量索引。Cassandra 5.0 也把 Vector Search 放进了官方文档。几个名字摆在一起信号很明显向量检索正在变成数据库的一项能力像全文索引、JSON 字段、地理空间查询一样。刚开始是单独产品最先把体验做出来后来通用数据库把常用能力吸进去最后大部分业务在原来的数据库里顺手解决。只有规模、过滤、延迟、运维形态真的卡住时才会单独拉一套专业系统。全文搜索以前也有专门系统后来 MySQL、Postgres、SQLite 都有基础全文能力但 Elasticsearch 仍然活得很好。原因很简单通用数据库吃掉的是基础需求复杂搜索体验还是需要专门系统。向量数据库已经有这个味道了。厂商基准能看但别当判决书Timescale 的pgvectorscaleREADME 里有个很有冲击力的 benchmark5000 万条 Cohere embedding、768 维、99% 召回Postgres pgvector pgvectorscale 对比 Pinecone 的 storage optimized indexp95 延迟低很多吞吐也高很多还说自托管成本低。这组数字很适合传播也很适合谨慎看。厂商 benchmark 永远带立场。数据集、查询分布、过滤条件、部署方式、成本算法换一个就可能变样。不过它至少说明一件事专用向量数据库已经没法只靠“我更快”三个字躺着收费了。Postgres 生态追上来的速度比很多人预期快。资本和产品动作也在往 Postgres 方向挤。Databricks 收 NeonSnowflake 收 Crunchy DataSupabase 这种 Postgres 平台估值一路抬高。它们不都是为了向量搜索但 AI 应用把“应用数据 检索 事务 权限 开发体验”重新绑到一起Postgres 这张老牌桌子又热了。向量数据库的压力就在于如果只是存向量和查近邻老数据库会越来越够用。天花板高的地方不叫“向量数据库”向量检索还没定型的地方在检索链路。生产级 RAG 很少只靠向量召回产品型号、合同编号、错误码、API 名光靠语义相似度会漏。BM25 关键词召回得进来元数据过滤得进来rerank 得进来权限、租户、时间衰减、文档版本也都得进来。一条看起来简单的问答链路最后会变成这样query - query rewrite - BM25 召回 - vector 召回 - metadata filter - merge / dedup - rerank - permission check - context packing - LLM“向量数据库”四个字盖不住这条链路。它更像检索基础设施或者 AI 应用的 memory layer。向量库只是其中一块位置还挺靠下。选型别按品牌按疼点真做项目时别一上来问 Milvus、Qdrant、Pinecone、pgvector 哪个最强。问法本身容易把事情带偏。先看哪块疼。触发条件更像该选什么原因数据量还在百万到千万级业务数据本来就在 Postgrespgvector / pgvectorscale同库事务、权限、备份、开发体验都省事过滤条件复杂租户、标签、时间、权限一起上Qdrant / Weaviate / 专用库过滤和向量检索的组合能力更关键上亿级向量、需要分布式、团队有运维能力Milvus / 专用集群数据规模和扩展性开始压过开发便利不想养基础设施预算能接受Pinecone 等托管服务省人但成本和迁移弹性要提前算主要是混合检索、全文搜索、日志和文档搜索Elasticsearch / OpenSearch / Vespa 等搜索系统向量只是检索链路的一部分只是内部知识库原型先别急着上专用库分块、召回、rerank 往往比数据库品牌更影响效果土办法反而管用先用已有数据库跑起来然后拿真实数据压三件事。过滤选择率降到 10%、1%、0.1% 时TopK 还能不能凑够索引重建要多久期间线上服务怎么处理混合检索加 rerank 后端到端延迟能不能接受。压测结果说不清品牌选得再漂亮也没用。天花板被谁压低了向量数据库不会消失。Milvus、Qdrant、Pinecone、Weaviate 仍然有位置。规模够大、过滤够复杂、延迟要求够狠、团队想把检索能力单独平台化专用库还是有意义。但“只要做 RAG 就该上向量数据库”这句话已经过时了。向量检索的天花板没被压低独立向量数据库的默认购买理由被压低了。后面的默认路径会更像先在原有数据库或搜索系统里把向量能力用起来等过滤、规模、尾延迟、运维隔离真的卡住再把向量检索拆出去。分界线怎么画各家差异会很大。如果有团队在 pgvector 上扛过复杂过滤尤其是hnsw.iterative_scan、ef_search、租户过滤一起上的场景我倒挺想看实际配置和翻车点。比继续争“向量数据库有没有未来”有用多了。