向量数据库选型这事，社区里已经吵了两年，到现在也没有统一答案。有人说小项目用 Chroma 就够了，有人说干脆一步到位上 Qdrant，也有人言必称 Milvus。横评文章看得越多，反而越不知道该选谁。
但翻完最近几个月知乎、B站、小红书上的真实踩坑帖之后，我发现大多数选型失误根本不是不懂产品，而是跳过了最简单的一步：没先算清楚自己的数据量要吃掉多少内存。
先看两个方向相反的坑
一位朋友刚玩 RAG 就跟风上了 Qdrant，折腾部署、调参数花了整整两天，结果本地测试只有几万条文档，根本感受不到它的生产级优势，换成 Chroma 反而省下大量时间聚焦业务。知乎另一位则是反过来踩坑：团队图省事直接上了 pgvector，跑通 demo 只用了不到一小时，没想到数据量两个月就涨到了 2000 万行，向量检索延迟从最初的 30、40ms 一路飙升到 2 秒以上，后来靠知识库分表才解决问题。知乎
两个坑方向相反，道理是同一个：选型不是选"最强"，而是选和自己的数据量、所处阶段最匹配的那个。
先算一笔内存账
向量占多大内存，其实是可以口算的：float32 每个维度 4 个字节。常见的 768 维 embedding，一条向量约 3KB；1536 维约 6KB。再乘以条数：
10 万条 × 768 维 ≈ 300MB
100 万条 × 768 维 ≈ 3GB
400 万条 × 1536 维 ≈ 24GB，这已经是一个真实语义搜索项目的实际体量。小红书
1000 万条 × 768 维的原始向量约 31GB，这是今天刚发布的 Qdrant 压测报告所用的工作集规模。知乎
在这个基础上，再加 HNSW 图索引和 payload 元数据的开销，内存预算最好再多留三到五成。算完这笔账你就能对号入座：几万篇文档撑死十几万条向量，用哪个数据库差异都感知不到；选型真正分出胜负的，是几十万条往上。
四个选项，各有各的位置
Chroma：十万条以内的省心之选。它更像向量数据库里的 SQLite，单机、嵌入式，pip install 就能用，API 一只手数得过来。社区经验是 10 万条以内随便跑，超过之后内存就会明显吃紧。知乎所以原型期、小型 RAG 用它完全没毛病，省下的部署时间去调 prompt 更值。
pgvector：存量 PostgreSQL 团队的零成本选项。如果你的数据库本来就是 PG，装个插件就能跑通 RAG 流程。但社区共识是单表控制在 100 万以内，最多也别超过 500 万。知乎开头那个 2000 万行的翻车事故，就是超了阈值还硬扛的典型。
Qdrant：中间地带的主角。Rust 写的，Docker 单容器就能起来。有 B 站 UP 主实测过 n8n+Qdrant+Ollama 的本地知识库方案，Qdrant 只需要 200MB 内存就能流畅运行，个人电脑部署毫无压力。哔哩哔哩往上走它也不虚：社区里有人单实例跑了五千万向量，一次检索也只消耗几十或上百毫秒。知乎它的 payload 过滤也很对多租户场景的胃口——检索过程中直接按租户、部门这类字段过滤，避免了先全局召回再后过滤的开销和召回损失。小红书
Qdrant 的短板也得说清楚。生态比较新、中文资料少，连问大模型都查不出多少相关内容，遇到问题经常得硬着头皮翻英文文档。知乎
Milvus：亿级才考虑的重量级选手。它的集群模式要依赖 etcd、对象存储、消息队列，哪个伺候不好也不行。知乎所以社区里才有那句吐槽：不想养一个月薪三万的专职运维，就别轻易上集群。不过它最近动作不少，8 月初发布的 3.0 版本，把大量原本要靠应用层完成的排序、聚合等后处理直接下推进了引擎内部。知乎
厂商跑分打架，先看条件再下结论
7 月有一场值得一说的跑分：Elastic 官方宣称，他们的 DiskBBQ 在可比召回率下，向量搜索吞吐量最高能达到 Qdrant 的 7 倍，而且测试特意选在网络附加存储上——这恰好是 Qdrant 的劣势场景，它的重排序阶段要从磁盘随机读原始向量。知乎
但报告自己也承认，Qdrant 在本地 NVMe 上通常表现更好，换用本地盘的部署结果可能完全不同。知乎所以看厂商基准测试，先问两件事：存储拓扑是什么，召回率有没有对齐。如果你的服务器插的是本地 SSD 甚至 NVMe，那这个 7 倍的参考价值就很有限了。
内存不够时，量化是官方答案
如果数据量上去了、内存不够用，Qdrant 给出的解法是量化压缩：把原始 Float32 向量压缩为 INT8 精度，数据量直接缩减到原来的 1/4。知乎
极限场景下能省多少？SmartX 今天发布的 Qdrant v1.18.2 压测里就有答案：仅用 16G 内存承载千万级向量（工作集约 31GB），开启 INT8 压缩加重排序后，依然能保持 570+ QPS 和 0.93+ 的召回率。知乎
不过免费午餐是有代价的。纯量化、不做重排序的话，召回率会从 0.93 掉到约 0.85，大约 15% 的真实最近邻会被漏掉。知乎对召回敏感的知识库问答，rescore 这步千万别省。
照着数据量对号入座
说了这么多，落到行动就是一张表：
向量数 10 万以内：用框架自带的或 Chroma，别在选型上花超过半天。
10 万～500 万：Qdrant 单节点，Docker 一行命令起，200MB 的内存占用对个人和小团队最友好。
500 万～千万：Qdrant + INT8 量化；深度绑定 PostgreSQL 的，也可以考虑 pgvector 分表。
上亿才轮到 Milvus，而且先把运维人手安排好。
社区里流传的一句口诀总结得很到位：规模小用 pgvector，规模中偏并发用 Qdrant，规模极致才上 Milvus。小红书
什么时候该考虑换库？也有人给出过经验阈值：向量超过 50 万、QPS 超过 100，或者搜索延迟已经开始影响主库，就可以考虑迁移到专用向量层了。小红书
最后说句宽心话：主流向量库的存储结构都是"向量 + 元数据"，真到了要迁移那天，重跑一遍 embedding 才是大头，数据搬迁本身没有想象中可怕。先跑起来，再跟着数据量演进，永远没毛病。
你的知识库现在用的是哪一个？踩过什么坑？评论区聊聊。
