向量数据库解决的不是「存向量」这种小事——任何能存数组的库都能存向量，它解决的是「在百万、千万级向量里按相似度毫秒级召回」。当知识库问答从 Demo 走向生产，检索的召回率和延迟就是天花板，这时候继续用 MySQL 的 LIKE 或全文索引硬扛，本质是拿关系型引擎做它不擅长的事。
先给结论：绝大多数团队缺的不是更贵的向量库，而是先换掉 embedding 模型和检索策略——召回率的天花板由 embedding 质量决定，不是向量库。库只是把该召回的东西找回来，找不回来说明向量本身没学出语义。
能力边界
专用向量库和通用库加向量扩展，是两条路线，边界在规模、混合检索和运维三处。
专用库（Milvus、Qdrant、Weaviate、Chroma）的性能天花板高，代价是多维护一套存储和一套部署。通用库的向量扩展（pgvector、ES/OpenSearch kNN、Redis Vector）运维成本几乎为零，代价是极限性能不如专用库。
混合检索是个分水岭。生产级 RAG 几乎没有纯向量就能做好的，都要「向量 + 关键词（BM25）」双路召回再融合，因为精确名词、编号、型号这类查询，向量召回经常抓瞎，关键词反而稳。所以选型时要看这个方案有没有原生、好用的混合检索，而不是只比单路向量的 QPS。
一张对比表
| 方案 | 规模上限 | 混合检索 | 运维成本 | 适配场景 |
|---|---|---|---|---|
| pgvector | 千万级 | SQL + 全文检索 | 极低，复用现有 PG | 已有 PostgreSQL、要事务和 JOIN |
| Qdrant | 千万~亿级 | 原生强 | 低，单二进制 | 自托管生产的稳妥默认值 |
| Milvus | 十亿级 | 需搭配 | 中高，etcd+MinIO+K8s | 亿级向量、高 QPS、有专职运维 |
| Weaviate | 亿级 | 原生 | 中 | 需要图关系与多模态的对象型 |
| ES/OpenSearch | 亿级（成本高） | 原生强 | 中 | 已有搜索栈，BM25+kNN 一体 |
| Redis Vector | 百万级 | 有限 | 低 | 内存友好、低延迟小规模 |
| Pinecone/云托管 | 无硬上限 | 支持 | 零 | 预算充足、不想碰运维 |
这张表的「规模上限」是量级参考，不是硬边界；实际能扛多少取决于硬件和索引参数。别拿它当承诺，拿它当排序依据。
选型建议
给 Java 工程师一句能直接用的口诀：有 PostgreSQL 就用 pgvector，没有 PG 就用 Qdrant，真到亿级向量、高 QPS 再上 Milvus。背后的逻辑是——先用几乎零运维的方案把 RAG 跑起来、把数据链路和评估跑顺，等量真的上去了，再为性能买单。过早引入 Milvus 这种重组件，是把运维成本前置到一个你还没验证的需求上。
选定方向之前，先回答五个问题：数据量能不能全放内存、标量过滤占比多少、召回率底线多少、P99 延迟要多少、Top-K 取多大。这五个问题答完，选型方向定了八成。
一条能跑的基线
下面两条语句给一个 pgvector 的起步基线，跑在现有 PostgreSQL 上，不加任何新服务：
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE doc_chunks (
id bigserial PRIMARY KEY,
doc_id bigint NOT NULL,
content text,
embedding vector(1024)
);
CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops);
SELECT id, content
FROM doc_chunks
ORDER BY embedding $1
LIMIT 5;
` 是 pgvector 的余弦距离算子，vector_cosine_ops让它走 HNSW 索引。1024 这个维度要跟你的 embedding 模型输出对齐，换模型就改这里。想加关键词路，PostgreSQL 的tsvector` 加 GIN 索引是现成的，双路召回再用 RRF 融合即可。
不适合谁
如果你的数据量在百万级以内、查询量不大，向量库都不是刚需，一个进程内方案或直接 pgvector 就够，上 Milvus 纯属给自己加负担。反过来说，如果你已经有 Elasticsearch 团队和搜索栈，别为了「专用向量库」再引入一个新组件，ES 的 kNN 加 BM25 天生一体，复用比新建划算。选型的原则是「离你现有栈最近的那条路，往往是对的」，不是「性能最猛的那个」。