2026 向量数据库怎么选：pgvector、Qdrant、Pinecone 与 Weaviate 全面对比

如果产品团队已经在用 Postgres，pgvector 通常是最合适的向量数据库；难点在复杂条件下的向量检索时，Qdrant 更占优势；最看重免运维体验时，应优先考虑 Pinecone；如果关键词搜索仍是产品核心，Elasticsearch 才是更合理的选择。截至 2026 年 7 月 30 日，各厂商公开的付费起步价从 Redis Essentials 的每月 $5 到 Elastic Cloud Hosted Standard 的每月 $99 不等，但选错数据模型造成的成本，往往远高于订阅费。

向量数据库对比速览

最稳妥的默认方案，是先让向量与应用数据共处一处，直到这种架构无法满足经过量化的检索要求。专用向量数据库可以改善条件过滤、扩展能力或运维体验，但也会引入第二套持久化数据系统，需要额外处理同步、备份、权限与故障责任。

下表价格均于 2026 年 7 月 30 日在厂商实时定价页面核验。“起步价”仅指公开的最低准入价格，并不代表该档位足以承载所有生产负载。

最简洁的决策规则，要从架构出发：

• 如果权威数据源是 Postgres，先用 pgvector。
• 如果确实需要专用开源引擎，选 Qdrant。
• 如果摆脱数据库运维比压低账单更重要，选 Pinecone。
• 如果负载规模大且冷热不均，把 turbopuffer 与 Pinecone 放在一起测算。
• 如果混合相关性需要一套可配置的产品层，选 Weaviate。
• 如果多向量规模才是核心难题，选 Zilliz Cloud；若团队具备分布式系统运维能力，也可以自行运行 Milvus。
• 如果应用已经运行在 MongoDB、Elasticsearch 或 Redis 上，先用现有系统的向量搜索，再考虑增加第二套数据库。
• 如果只是做本地原型，选 Chroma，生产环境则要另行决策。

只要关键要求改变，结论就会翻转。带过滤条件的近似搜索无法在延迟预算内返回足够候选项时，pgvector 就不再合适；团队无人愿意维护另一项服务，而 Cloud 价格又无法在容量评估前预测时，Qdrant 的优势会消失；用量单位或控制权要求超过免运维收益时，不该选 Pinecone；为了单一相似度功能买下整套搜索平台时，Elasticsearch 就显得过重。

这份向量数据库推荐如何筛选

向量数据库用于存储嵌入向量——也就是文本、图像、音频等数据的数值表示——并按相似度找出距离最近的内容。定义不难，真正困难的是生产选型。

榜单收录十款产品，因为每款都在一种明确的工作负载中有胜算；继续增加产品只会重复已经覆盖的决策。评估围绕七项难以逆转、代价高昂的约束展开：

• 数据重力： 规范文档、用户、权限和业务记录目前存在哪里。
• 带过滤召回率： 应用租户、权限、地域、状态或时间条件后，引擎能否返回足够多的相关结果。
• 混合检索： 如何把稠密语义相似度与稀疏匹配或关键词匹配结合起来。
• 写入行为： 更新多久后可被检索，以及建索引、缓存预热或故障切换期间会发生什么。
• 运维负担： 副本、升级、备份、容量、索引内存与事故响应由谁负责。
• 计价单位： 按存储、读写单元、逻辑字节、集群资源、支持承诺，还是基础订阅计费。
• 退出成本： 更换产品只是替换扩展、迁移索引，还是要重建两套数据库之间的同步链路。

本文对这些产品做的是价格核验与架构分析，并未声称完成了实机压力测试。不同厂商的基准测试不可直接横向比较，因为向量维度、召回率目标、过滤条件、硬件、索引配置和数据分布都会改变结果。缺少这些控制变量的 benchmark，不过是拿着秒表的广告。

这次对比得出的核心结论很简单：不存在一个对所有团队都负责的“向量数量迁移阈值”。只有当前系统在带过滤召回率、延迟、写入可见性、索引内存或运维负担上无法满足既定服务指标时，才该迁移。权限过滤苛刻的团队，可能比拥有更大无过滤语料库的团队更早触及架构上限。

1. pgvector：Postgres 团队的综合首选向量数据库

对多数应用团队而言，pgvector 是最合适的向量数据库，因为它直接为团队已经会保护、备份、查询和维护的 Postgres 增加相似度搜索。嵌入向量可与客户、文档、权限及事务记录放在一起，由此省掉一整条同步边界。

一个典型场景是 B2B SaaS：文档、账户成员关系、权益与审计记录都在 Postgres 中。检索可以直接关联或过滤同一份关系数据，不必把授权元数据复制到另一项服务，再祈祷每次更新都能赶在下一次查询前同步完成。相比赢下一场合成最近邻 benchmark，这种架构简洁性通常更有价值。

pgvector 支持精确和近似最近邻搜索，适用于 Postgres 13 及更高版本，同时保留 Postgres 的常规优势：ACID 事务、时间点恢复、JOIN、副本以及熟悉的监控体系。它提供两类近似索引：

• HNSW 是多层图索引，速度与召回率的平衡更好，但构建更慢、占用内存更多。
• IVFFlat 是倒排文件索引，构建更快、占用内存更少，但在相近召回率目标下会牺牲查询性能。

检索延迟重要时，HNSW 是合理的首个生产索引。构建时间、内存或批量加载流程占主导时，才值得考虑 IVFFlat。无论选哪一个，都仍需用应用自身的过滤条件实测召回率。

真正的瓶颈出现在带过滤条件的近似搜索。pgvector 扫描近似索引后才应用过滤器。其文档给出了一个很直观的例子：若条件仅匹配 10% 的行，且 HNSW 使用默认 hnsw.ef_search 值 40，平均只有四行会命中。此时即便相关记录确实存在，请求 top 10 也可能拿不到 10 条结果。

0.8.0 版本加入了迭代式索引扫描，可持续扫描，直到找到足够的过滤后结果或达到扫描上限。这是实质性的改进，却不是没有代价的万能解法：扫描越多，延迟与工作量越大。过滤值少且稳定时，部分索引有效；租户或类别足够多、值得物理隔离时，分区有效。如果这些手段仍达不到服务指标，专用引擎才真正有吸引力。

维度上限同样写得很明确。HNSW 与 IVFFlat 可为最高 2,000 维的 vector、最高 4,000 维的 halfvec 和最高 64,000 维的 bit 建索引；不建索引的 vector 类型最多可存 16,000 维。多数文本嵌入模型都在范围内，但高维或多向量设计必须在定型前核对索引表示。

混合检索能力不弱，不过需要自己组装。pgvector 可与 Postgres 全文搜索配合，让团队在同一数据库中同时运行语义检索与词法检索，再融合排序。优点是掌握控制权并统一数据模型；代价是相关性调优、排序融合和评估都要由应用团队完成。

最适合： 权威数据已在 Postgres 中的 SaaS 产品、内部工具和 RAG 系统
突出优势： 向量、权限、关系过滤与应用记录共用一个事务数据模型
价格： pgvector 是开源软件，没有厂商订阅档位。成本来自应用数据库本就需要承担的 Postgres 基础设施、存储、副本、备份和工程时间。
免费试用： 不适用；该扩展为开源软件

pgvector 安全上线流程

只有不让检索拖垮应用数据库，这个首选才站得住。先建立测量闭环，再把相似度搜索放进关键路径。

1. 1

   在生产所用 Postgres 版本上安装扩展

   确认部署环境运行 Postgres 13 或更高版本，通过云厂商或包管理系统安装 pgvector，并用 CREATE EXTENSION vector 启用。扩展版本应纳入数据库发布管理，而不是当作可独立漂移的应用依赖。

2. 2

   把源记录与嵌入向量放在一起

   将嵌入向量放在受同一套权限与生命周期控制的源记录行中，或放在通过外键关联的子记录中。同时保存嵌入模型标识，便于未来迁移模型时区分新旧向量。

3. 3

   先做精确搜索，再加 HNSW

   先在代表性样本上跑精确搜索，建立召回率基线；有了基线后再增加 HNSW，并针对固定评估集调整候选列表，而不是只追求延迟数字。

4. 4

   测试最棘手的权限过滤条件

   既要测试选择性最低的租户或权限条件，也要测试选择性最高的条件，不能只跑无过滤查询。如果近似搜索返回的行数不足，启用迭代扫描，并在考虑更换数据库前测清新增延迟。

5. 5

   只有服务指标失守时才拆分负载

   经过索引与分区优化后，如果带过滤召回率、索引内存、写入负载或查询延迟仍达不到既定目标，再迁移到 Qdrant、Pinecone 或其他专用引擎。Postgres 仍应保留为权威数据源，并明确设计同步契约。

如果后端本身都还没确定，应先解决这个问题。Supabase 与 Firebase 对比解释了为什么在检索流量出现之前，应用数据模型就可能已经决定向量数据库的选择。

2. Qdrant：专用开源向量数据库首选

如果团队需要复杂元数据过滤、开源控制权，同时希望运维形态比大型自托管 Milvus 更简洁，Qdrant 是最值得优先评估的专用向量数据库。当 pgvector 的带过滤召回率已成为量化确认的瓶颈，它就是第一个候选。

典型用例是多租户知识产品：每次查询都必须将语义相似度与账户、地域、文档类型、状态、访问组等嵌套条件结合。Qdrant payload 可存任意 JSON，过滤模型支持 must、should、must_not、范围、匹配与嵌套键。这样一来，带授权约束的检索查询直接在引擎中完成，而不再是结果返回后的二次处理。

Qdrant 也支持稠密与稀疏混合检索。从 1.10.0 版本开始，其多阶段查询系统可以通过 reciprocal rank fusion（RRF）或 distribution-based score fusion（DBSF）融合结果集。RRF 按结果顺序而不是原始分数合并，因此无需假定词法分数与稠密向量分数处于同一量纲。

产品有两种定位清晰的形态。Qdrant OSS 让团队完全掌控软件，同时也把基础设施责任交给团队；Qdrant Cloud 则省掉大部分运维，但仍需按资源确定集群规格。Qdrant 实时定价页面显示，Free Tier 是单节点配置，包含 0.5 vCPU、1 GB RAM 和 4 GB 磁盘。Standard 按专用资源的实际用量计费，支持纵向与横向扩展、高可用配置、备份与灾难恢复，并提供 99.5% 可用性 SLA。

Premium 要求最低消费，但 Qdrant 未公布具体金额。该档位增加 SSO、私有 VPC 连接、额外支持和 99.9% 可用性 SLA。Hybrid Cloud 由 Qdrant 的管理平面管理客户基础设施中的部署；Private Cloud 面向隔离或气隙环境，两者都需要联系销售。

价格方面的门槛在于预测。Standard 根据 vCPU、内存、集群存储、备份存储和付费推理 token 按小时计费。完成容量评估后，这种模式并不难理解，但无法负责任地给出一个统一月费。采购团队应将生产环境的向量维度、副本、存储和写入速率填入计算器，再分别测试较小与较大的集群，以看清升级台阶。

架构门槛与所有专用引擎一样：Qdrant 会成为派生数据存储，源记录仍在别处。删除、权限变更、重新嵌入、灾难恢复与重放都需要清晰契约。只有检索表现足以回报这套新增系统时，Qdrant 才算真正胜出。

最适合： 带嵌套元数据、租户或权限过滤的专用向量检索
突出优势： 表达力强的 payload 过滤，以及开源与托管两条部署路径
价格： OSS 开源。Cloud Free 永久免费，包含 0.5 vCPU、1 GB RAM 和 4 GB 磁盘。Standard 按资源用量逐小时计费。Premium 有最低消费要求，需询价。Hybrid Cloud 与 Private Cloud 均为询价。
免费试用： Cloud Free Tier

3. Pinecone：免运维托管向量数据库首选

如果小型工程团队更看重全托管检索服务，而不是开源控制权或最低基础设施成本，Pinecone 是更合适的向量数据库。容量、副本、备份和索引可用性都由厂商承担；对于核心竞争力并非数据库运维的产品，这笔投入可能完全合理。

最典型的用户，是没有数据库专家、却要上线语义搜索或 RAG 的已融资产品团队。Pinecone 提供稠密、稀疏和全文索引选项、按需 Serverless 基础设施、生产方案的备份恢复，以及企业部署控制。它的价值不是让存储凭空消失，而是以清晰 API 买到一项运维面更少的检索服务。

Pinecone 实时定价结构分为四档。Starter 免费，最多包含 2 GB 数据库存储、每月 2 million 个写入单元、1 million 个读取单元和 1 GB 出站流量。Builder 为固定 $20/月，最多包含 10 GB 存储、5 million 个写入单元、2 million 个读取单元和 10 GB 出站流量。

Standard 的最低月费为 $50，可抵扣实际用量；同时提供 3 周试用和 $300 额度。数据库存储费为每月每 GB $0.33。根据云与区域不同，每 million 个写入单元收费 $4 至 $4.50，每 million 个读取单元收费 $16 至 $18。每月含 100 GB 出站流量，超出后每 GB $0.10；导入每 GB $0.25，备份存储每月每 GB $0.10，恢复每 GB $0.15。

Enterprise 将最低月费提高到 $500。存储仍是每月每 GB $0.33，写入则升至每 million 个 $6 至 $6.75，读取升至每 million 个 $24 至 $27。该档位增加 99.95% 可用性 SLA、BYOC、私有端点、客户管理密钥、审计日志、SCIM、HIPAA 合规与 Pro 支持。

Pinecone 的混合搜索能力完整，但有一个必须说明的技术细节。官方给出三种模式：在同一索引中存放稠密和稀疏向量；分别使用稠密与稀疏索引；或使用结合向量字段与全文字段的文档 schema。对于多数使用 vector API 的场景，Pinecone 推荐单索引向量模式，因为只需一次请求，并能保持两类向量的关联。

不过，单索引模式不会自动归一化稀疏与稠密分数。对归一化嵌入而言，稠密点积大致限制在 -1 到 1 之间；BM25 风格的稀疏分数没有上限，因而可能压过稠密结果。应用必须显式设置 alpha 权重。该模式也不能执行纯稀疏查询，且无法使用集成式嵌入与重排。拆成两个索引可恢复这些能力，却会增加两次查询，以及显式关联、合并、去重和重排工作。

它真正的门槛是成本可观测性。Pinecone 公开了单位价格，这比隐藏价格更透明，但团队仍需用有代表性的读取、写入、存储、备份与出站流量做测算。$50 的最低消费很有吸引力，持续查询或频繁重新嵌入后，账单却可能完全不同。应在上线前按客户和工作流记录用量单元，避免汇总数据再也无法归因。

最适合： 希望获得托管生产检索、又不想运维向量集群的小型团队
突出优势： 从 API 集成走向厂商托管生产服务，路径最简洁
价格： Starter 免费。Builder 固定 $20/月。Standard 最低 $50/月，另按实际用量计费。Enterprise 最低 $500/月，读写单价也更高。Standard 与 Enterprise 的数据库存储均为每月每 GB $0.33。
免费试用： Starter 免费；Standard 提供 3 周试用和 $300 额度

4. turbopuffer：大规模、冷热不均 Serverless 负载首选

如果检索语料库规模很大、访问分布又极不均匀，常驻内存并不划算，turbopuffer 是值得重点考虑的专用方案。其商业模式围绕逻辑存储、写入量与查询字节数展开，而且所有方案都包含完整数据库功能。

典型场景是拥有大量隔离客户 namespace 的产品：大部分冷数据形成长尾，检索请求却集中爆发在较小的活跃数据集上。它的查询 API 支持近似与精确最近邻搜索、BM25 全文搜索、稀疏向量、过滤、排序、查找、聚合及多查询检索。混合搜索可同时运行向量与 BM25 分支，再通过 RRF 融合。

turbopuffer 定价中，Launch 的最低月费为 $16。Scale 最低月费升至 $256，并增加符合 HIPAA 要求的 BAA、SSO、审计日志、IP 白名单、私有 Slack 频道和 8-to-5 时段支持。Enterprise 每月至少 $4,096，另收 35% 用量溢价；该档位提供单租户、BYOC、私有网络、每个 namespace 的客户管理密钥、24/7 支持和 99.95% 可用性 SLA。

其计价单位需要仔细读懂。2026 年 2 月调整后，基础查询数据费率为每 PB $1，每次查询的最低计费数据量为 1.28 GB。可过滤属性会按每个向量列分别计算写入与存储费用；不可过滤属性则无论向量列数量多少，都只存储一次。因此，文档数量相同的两个 schema，如果其中一个把大量属性设为可过滤，或增加了向量列，成本也会不同。

明确的限制是大规模更新期间的写入可见性。turbopuffer 表示，超过 99.8% 的查询会返回一致数据；少数扩容或故障切换可能造成约 100 ms 的陈旧。当某个 namespace 的待处理写入超过 128 MiB，后续写入可能要等到完成索引并加载进缓存后才可见。官方记录的延迟，小型 namespace 可能是数十秒，大型 namespace 可能是数十分钟；发生重大写入后，数据最多可能陈旧约一小时。

对于按批次更新的知识语料库，这种行为可以接受；若权限撤销或紧急发布必须在下一次查询就生效，则完全不可接受。产品需要明确的 freshness 服务指标，不能只贴一个泛泛的“最终一致”标签。

聚合还有另一条边界：对于超过 1 million 文档的 namespace，turbopuffer 不建议在延迟敏感的工作负载中使用聚合。应把它当作检索引擎，不要因为 API 能计数和分组，就悄悄把它变成分析数据库。

最适合： 大型多租户语料库、访问冷热不均，且团队能接受按字节计费
突出优势： 以较低承诺门槛提供向量、BM25、稀疏及混合检索
价格： Launch 最低 $16/月。Scale 最低 $256/月。Enterprise 每月至少 $4,096，另加 35% 用量溢价。超过承诺额度后，费用由存储、写入和查询字节数决定。
免费试用： 定价页面未公开列出试用

5. Weaviate：托管混合搜索工具链首选

如果团队希望把混合检索、可配置相关性、多租户和托管部署放进同一款产品，而不是在应用代码中自行拼接每一个搜索阶段，Weaviate 是更合适的向量数据库。它更像完整的检索平台，而不是一个单薄的最近邻服务。

典型用例是多租户客服或电商搜索：精确短语、语义相似度、时效性和租户隔离都会影响排序。Weaviate 的混合搜索把向量结果与 BM25F 关键词结果融合。应用可通过 alpha 调整关键词与向量的权重，选择融合方法、查看分数解释、应用过滤器，并按属性或衰减规则对融合候选池加权。

Weaviate 托管 Free 方案永久为 $0，包含 100,000 个对象、1 GB 内存、10 GB 磁盘、一个 collection 和最多三个租户。它足以验证数据模型和相关性，但没有副本，仅提供尽力而为的可用性。

Flex 在共享集群上起价 $45/月，按用量付费且无需承诺，包含副本、RBAC、7 天备份保留、99.5% 可用性目标，以及下一个工作日响应的 Severity 1 支持。Premium 在预付承诺下起价 $400/月，可选择共享或专用部署，备份保留期为共享 30 天或专用 45 天，并提供 SSO/SAML、最高 99.95% 可用性，以及最快一小时响应的 Severity 1 支持。

三种方案都包含混合搜索和多租户。团队可以先在 Free 上验证检索模型，不会到后来才发现核心查询形态被锁在企业档位后面。付费决策真正对应的是容量、可靠性、备份、安全、区域和支持。

它的门槛在于配置面广。相关性平台之所以有更多旋钮，是因为必须有人持续负责。alpha 值、融合方法、分词器、过滤器和加权规则都能改善结果，也可能在六个月后留下无人解释得清的排序系统。每一次相关性变更都应同时保存评估结果与回滚路径。

第二道门槛是价格跳档。Flex 每年起价 $540，Premium 每年起价 $4,800，最低价相差近九倍，尚未计算负载波动。需要 SSO、更强支持、更长备份、更多区域或专用部署时，高档位有合理价值；不能只因为“生产”听起来就该配 Premium 而购买。

最适合： 需要调校词法与语义相关性的多租户产品
突出优势： 在托管检索平台中配置 BM25F 与向量融合
价格： Free 永久 $0。Flex 起价 $45/月。Premium 的共享或专用部署起价 $400/月。按量计费的嵌入与 Query Agent 服务另计。
免费试用： 永久免费托管档

6. Zilliz Cloud 与 Milvus：超大规模和多模态集合首选

当集合规模、多向量字段或多模态检索成为核心工程问题时，Zilliz Cloud 是更合适的托管向量数据库；它的底层开源引擎是 Milvus。托管产品之所以值得溢价，是因为它卸下了相当沉重的分布式系统运维工作。

典型场景是商品目录：同一商品同时包含语义文本向量、稀疏关键词向量和图像向量。Zilliz Cloud 可以跨这些字段执行多次 ANN 搜索，再对合并结果重排。其官方混合检索示例，在同一个 collection 中使用了稠密文本、内置 BM25 稀疏文本和稠密图像向量。

Zilliz Cloud Free 方案为 $0，包含 5 GB 存储、每月 2.5 million vCUs 和最多五个 collection。Standard Serverless 起价为 $0/月；定价页对 Dedicated 展示的起价标签是“From $126/GB/month.”。Standard 与 Enterprise 都提供 30 天试用。

Enterprise Dedicated 起价 $197/月，并增加 99.95% 可用性 SLA、审计日志、SSO、细粒度 RBAC、多副本扩展、私有端点或 VPC peering，以及企业支持。Business Critical 采用询价模式，面向监管严格或任务关键型部署，提供更强的韧性与安全性。

专用集群的规格选择解释了为什么该产品位于榜单的规模端。performance-optimized 计算单元约对应 2 million 个 768 维向量，capacity-optimized 约对应 8 million 个，tiered-storage 约对应 40 million 个。公开的起价指标分别是每月每 million 向量 $63、$16 和 $5。这些只是规格估算，不能取代 PoC。

自托管 Milvus 的门槛在于运维复杂度。大型集合、多种索引、副本、compaction、存储、升级与恢复共同构成一套真正的平台。如果团队原本没有人负责这些工作，仅仅因为软件开源就自行运行 Milvus，最终成本可能高于 Zilliz Cloud。

第二道门槛是采购透明度。Zilliz 提供了一些有用的起点，但生产估价仍取决于集群类型、计算单元、副本、存储、负载和方案。任何延迟或成本报价，都必须同时注明计算器中的具体规格。

最适合： 超大集合、多模态数据，以及多个稠密或稀疏向量字段
突出优势： 托管 Milvus，支持多向量混合搜索与面向不同规模的集群规格
价格： Free 为 $0。Standard Serverless 起价 $0/月；页面显示 Standard Dedicated 起价为 $126/GB/month。Enterprise Dedicated 起价 $197/月。Business Critical 为定制价格。
免费试用： 免费方案；Standard 与 Enterprise 提供 30 天试用

7. MongoDB Atlas Vector Search：应用数据已在 MongoDB 时首选

对于 MongoDB 应用，MongoDB Atlas Vector Search 是最顺理成章的向量方案，因为它让嵌入索引与负责字段和生命周期的原始文档放在一起。这与 pgvector 成为 Postgres 默认选项的“数据重力”逻辑完全相同。

典型场景是权威对象已经以 MongoDB 文档存储的商品目录、内容平台或 Agent 系统。$vectorSearch 聚合阶段可以在语义搜索前预过滤文档，让类别、账户、locale、库存状态等字段继续留在同一个查询面中。

Atlas Free 为 $0，提供 512 MB 和共享计算。Flex 每小时 $0.011，每月封顶 $30，提供最多 5 GB 和共享计算。Dedicated 起价为每小时 $0.08，或每月 $56.94，配置包括 10 GB 存储、2 GB RAM 和两个 vCPUs。

向量能力有清晰边界。$vectorSearch 接受最高 8,192 维的向量，运行要求为 Atlas 6.0.11 或更高版本。它不能出现在 $facet 或 $lookup 内；从 MongoDB 8.0 开始，可以在 $unionWith 内运行。如果团队默认所有常规 pipeline 形态都能包裹向量检索，这些聚合限制就会成为关键问题。

搜索也可以迁移到专用 Search Nodes，与数据库计算隔离。Atlas 支持两个到 32 个 Search Nodes，并按节点档位逐小时收费；Search Nodes 与数据库节点之间的网络传输会计入集群费用。这样解决了 noisy-neighbor 问题，同时也增加了新的容量与成本维度。

它的门槛，是在应用原本并不需要 MongoDB 时仍为 MongoDB 付费。Atlas Vector Search 是继续留在 MongoDB 的好理由，却不是把关系型应用迁入 MongoDB 的强理由。若只为向量而选它，就会额外引入文档模型、集群与搜索节点决策；pgvector 或专用引擎往往更简洁。

最适合： 想做语义搜索、又不想增加数据存储的现有 MongoDB Atlas 应用
突出优势： 直接对同一份应用文档字段执行向量预过滤
价格： Free 为 $0。Flex 每小时 $0.011，每月最多 $30。Dedicated 起价为每小时 $0.08 或每月 $56.94。专用 Search Nodes 另按节点小时收费。
免费试用： 永久免费的 Atlas 档位

8. Elasticsearch：词法搜索仍是产品核心时首选

当全文相关性、过滤、聚合和业务搜索本就是产品核心，语义检索只是新增信号时，Elasticsearch 才是最合适的向量数据库。对单一 RAG 索引而言，它并不是经济的默认选项。

典型场景包括电商、媒体、可观测性或企业搜索：精确词、短语、分面、结构化过滤和语义相似度必须共用一个引擎。Elasticsearch 用 dense_vector 存储稠密嵌入，用 sparse_vector 存储稀疏嵌入，并将它们与词法检索、过滤和聚合结合。

混合检索可以在同一工作流中运行关键词、kNN、稀疏向量和语义分支。Elastic 支持 reciprocal rank fusion 与 linear fusion，随后还可选择重排。只有当相关性工程本身是一项产品能力，而不是 LLM 后面的辅助函数时，这种广度才真正有价值。

Elastic Cloud Hosted 公布了四个起步价：Standard 每月 $99，Gold 每月 $114，Platinum 每月 $131，Enterprise 每月 $184；四档都提供免费试用。在工作负载带来的资源费用之外，其年度价格下限分别为 $1,188、$1,368、$1,572 和 $2,208。

向量存储不是一成不变的底层管道。维度至少为 384 的新建 float 或 bfloat16 向量索引，默认使用 BBQ HNSW；这种二值量化 HNSW 配置旨在降低内存和成本。默认值会随版本演进，因此检索评估必须带上版本信息。绑定某一种索引配置得出的相关性结果，不能被当成永久结论。

它的门槛是平台体量。Elasticsearch 能力面广，正因为它解决的问题也很广。集群、mapping、analyzer、shard、索引生命周期、相关性 pipeline、向量配置与升级都需要明确负责人。如果唯一查询只是“找出五个语义最相近的 chunk”，Pinecone、Qdrant、pgvector 或 Chroma Cloud 都更容易理解和维护。

最适合： 需要同时处理词法相关性、过滤、分面和向量的搜索产品
突出优势： 一个引擎完成关键词、稠密、稀疏、过滤、聚合与重排检索
价格： Cloud Hosted Standard 起价 $99/月，Gold 为 $114/月，Platinum 为 $131/月，Enterprise 为 $184/月。超过这些价格下限后，部署成本由资源用量决定。
免费试用： 所有托管档位均提供

9. Redis：检索必须紧邻实时状态时首选

如果嵌入向量必须与 Redis 中已有的快速变化会话状态、语义缓存、推荐或 Agent memory 放在一起，Redis 是最合适的向量方案。它的优势是贴近实时数据链路，而不是低价存储海量向量。

典型场景是 AI 应用已经在 Redis 中保存近期对话状态、缓存条目、用户特征或推荐候选项，并需要对同一批对象做语义查找。Redis 可以为 hash 或 JSON 文档中的向量建索引，并按文本、标签、数字、地理空间字段及向量条件过滤。

三种向量索引适配不同场景。当向量少于 1 million，或精确率比延迟更重要时，Redis 推荐 FLAT；数据集更大、速度和扩展性比完美精确更重要时，应选 HNSW。Redis 8.2 又加入 SVS-VAMANA，提供图结构压缩方案，也多了一组需要调整的参数。

Redis Cloud 定价中，Free 为 $0，包含一个最大 30 MB 的共享数据库。Essentials 起价每小时 $0.007 或每月 $5，容量从 250 MB 到 100 GB，跨 RAM 与 SSD，并提供 SAML SSO、RBAC、加密及最高 99.99% 可用性。Pro 起价每小时 $0.014，最低月费 $200，且首个 $200 免费；该档位增加专用部署、无限 RAM、多个数据库、Active-Active 多区域、私有连接与最高 99.999% 可用性。

多云、混合云与本地部署采用年度询价方案。那是企业采购路径，并不适合快速向量试点。

它的门槛是内存经济性。Redis 围绕快速数据访问设计，即便压缩或 SSD 支持的配置能缓解压力，向量索引仍会消耗内存。对于规模大、绝大部分是冷数据、仅偶尔查询的语料库，不应购买内存型系统；turbopuffer、Pinecone 或偏存储的 Zilliz 集群规格更值得建模比较。

最适合： 语义缓存、Agent memory、推荐，以及对 Redis 实时数据的检索
突出优势： 向量搜索与低延迟状态、JSON、hash 和元数据过滤共存
价格： Free 为 $0，最高 30 MB。Essentials 起价每小时 $0.007 或每月 $5。Pro 起价每小时 $0.014，最低月费 $200，首个 $200 免费。企业部署按年度方案询价。
免费试用： 免费档；Pro 包含首个 $200

10. Chroma：本地原型与简单云端检索首选

Chroma 是本地原型的首选向量数据库，也能胜任简单的云端检索产品；但它的本地与云端能力并不完全一致。从 notebook 迁移到 Chroma Cloud 应被视为一次生产架构决策，而不是点一下部署按钮。

它很适合产品外围尚未稳定、工程师正验证 chunking、嵌入、过滤和检索表现的阶段。Chroma 的开源开发体验让这个循环很容易启动；Chroma Cloud 则增加 Serverless 向量、全文和元数据搜索，并公布明确的用量价格。

Chroma Cloud Starter 的基础月费为 $0，另按用量收费，包含 $5 免费额度、10 个数据库和 10 名团队成员。用量价格为：每写入 GiB $2.50、每月每存储 GiB $0.33、每查询 TiB $0.0075，以及每返回 GiB $0.09。

Team 的基础月费为 $250，另按用量收费，包含 $100 额度、100 个数据库、30 名团队成员、Slack 支持、SOC II 和批量折扣。所含 $100 不可结转。Enterprise 为定制价格，增加无限数据库与团队成员、专属支持、单租户集群、BYOC 和 SLA。

许多团队会忽略 Search API 这条边界。Chroma 目前的 Cloud Search API 支持向量搜索、元数据与文档过滤、自定义排序表达式、RRF 混合搜索、分组、批量操作、字段选择和分页。Chroma 明确表示，该 API 目前仅在 Chroma Cloud 可用，单节点支持计划在未来版本提供。

这意味着，使用旧查询界面的本地 PoC 并不能自动验证云端生产查询方案；依赖 Cloud Search API 的设计也不能自然迁移到自托管单节点。产品名称相同，运维面与查询面仍要分别核验。

它的门槛出现在 Team 档的治理与费用。Starter 可以通过用量计费承载小型工作负载；Team 则在用量费之前就把基础成本提高到每年 $3,000。这个跳档换来组织容量、支持、SOC II 和折扣，应该对应明确的组织要求，而不是“付费才算生产”的模糊感觉。

最适合： 本地 RAG 原型、检索实验和结构简单的 Chroma Cloud 应用
突出优势： 本地启动迅速，云端写入、存储、查询和网络费率透明
价格： Starter 基础月费 $0，另按用量收费，含 $5 额度。Team 基础月费 $250，另按用量收费，含 $100 额度。Enterprise 为定制价格。用量价格为每写入 GiB $2.50、每月每存储 GiB $0.33、每查询 TiB $0.0075，以及每返回 GiB $0.09。
免费试用： Starter 包含 $5 额度

不同场景该选哪款向量数据库

向量数据库的正确选择，依次取决于权威数据源、最棘手的检索条件，以及团队愿意承担多少运维。

Postgres 已经保存业务记录：选 pgvector

当文档、用户、权限、事务和向量可以共用一套数据模型时，选择 pgvector。只要带过滤召回率、索引内存和查询负载尚未造成可量化的失败，就继续使用它。不要仅因为某项通用 benchmark 声称另一款引擎能处理更多向量而迁移。

如果启用迭代扫描、部分索引、分区和容量隔离后，延迟或召回率仍不达标，结论才会翻转。此时，Qdrant 是最强的专用开源候选，Pinecone 则是运维负担最低的候选。

过滤条件才是检索难题：选 Qdrant

当嵌套 payload 过滤与稠密+稀疏融合居于核心位置时，选择 Qdrant。它适合愿意运行第二套数据存储，或在容量评估后购买 Qdrant Cloud 的团队。如果数据库运维才是更大的约束，改选 Pinecone；如果过滤条件本质上是关系型的，且负载仍适合 Postgres，就回到 pgvector。

运维成本高于用量费：选 Pinecone

小团队需要托管服务、公开用量单价和企业控制，又不想自行运维集群时，选择 Pinecone。如果用量单位成本、混合搜索编排、BYOC 政策或开源控制权比便利性更重要，结论就会翻转。

托管与自持的比较，与其他 AI 基础设施决策具有相同的经济结构：要么向厂商付费，换取更窄的运维面；要么自己拥有系统，也承担它的事故。自建还是采购的成本框架说明了如何把工程维护成本与订阅费放在一起核算，而不是假设人力免费。

语料库庞大且冷热不均：选 turbopuffer

当逻辑字节计价与 namespace 隔离契合工作负载时，选择 turbopuffer，但必须对写入突发下的数据新鲜度做专项测试。如果更新或权限撤销必须在下一次查询就可见，或者团队需要更简单的计费方式，就应改选其他方案。

相关性需要完整产品界面：选 Weaviate

如果 BM25F、向量权重、融合、加权、多租户与托管部署都需要集中在一套平台中，选择 Weaviate。当查询简单到这些控制反而成为治理负担时，结论就会翻转。

难题在多向量与规模：选 Zilliz Cloud

超大规模、多模态或多向量字段集合应选 Zilliz Cloud。只有团队原本就具备分布式系统运维能力时，才选择自托管 Milvus。如果所谓“未来十亿级规模”只是故事，不是测量后的要求，就应改用更轻量的引擎。

数据重力占优：留在 MongoDB、Elasticsearch 或 Redis

应用文档已经在 MongoDB 中，就选 Atlas Vector Search；词法搜索、过滤和聚合是核心产品，就选 Elasticsearch；向量检索需要紧邻实时状态，就选 Redis。仅仅为了向量而迁入其中任何一款数据库，都不是好理由。

用 Chroma 学习，生产环境重新决策

本地使用 Chroma，可以验证 chunking、嵌入与检索。只有其用量模型和 Cloud Search API 与生产负载相符时，才选择 Chroma Cloud。不要假设本地与云端界面可以互换。

哪些场景应该避开这些产品

避开错误产品，比寻找一个万能赢家更重要。这里每款产品都有合理用例，也都有可能成为错误采购的明确方式。

• 在现有数据存储真正失效前，避免引入专用向量数据库。 把向量与元数据从 Postgres 或 MongoDB 复制出去，会新增同步、删除、恢复和访问控制工作。单纯 benchmark 领先，无法偿还这笔架构债。
• 调优后近似过滤仍无法返回规定数量时，避免 pgvector。 迭代扫描可以通过增加工作量找回记录；如果新增工作突破延迟预算，系统才真正到达迁移触发点。
• 没有人负责分布式存储与搜索运维时，避免自托管 Milvus。 开源许可证不会替你完成升级、容量规划、备份演练或值班。
• 无法建模读、写、存储、备份和出站单元时，避免 Pinecone。 托管服务省掉集群工作，却不会免除成本责任。
• 未经写入突发测试，不要让 turbopuffer 承诺“下一次读取必定一致”。 官方记录的缓存与索引行为是产品要求，不是一条无关紧要的脚注。
• 团队不维护相关性评估集时，避免 Weaviate。 没有量化结果，可配置融合与加权最终只会变成无人复核的经验传说。
• 只有向量功能时，避免 Elasticsearch。 这个搜索平台强大，正因为它能力广；如果完全用不到精确词、analyzer、facet 和聚合，这种广度就是浪费。
• 大型冷数据归档应避免 Redis。 Redis 的优势在快速实时状态；为极少查询的嵌入向量支付内存型成本，本末倒置。
• 设计依赖 Cloud Search API 时，避免 Chroma 单节点。 厂商目前明确将这套高级 API 标为 Cloud-only。

最常见的错误，是为未来的规模故事买单。只购买下一阶段生产环境中最棘手、已经可见的要求，同时保留经过验证的迁移路径。架构可以演进，未经量化的复杂度只会不断累积。

常见问题

RAG 最好的向量数据库是什么？

如果应用已经使用 Postgres，pgvector 是最稳妥的默认选择。复杂过滤场景下，Qdrant 是最佳专用开源方案；Pinecone 是最简单的全托管方案；当可配置混合相关性成为核心产品要求时，Weaviate 最有优势。

RAG 有哪些好用的免费向量数据库？

pgvector、Qdrant OSS、Milvus、Weaviate OSS、Redis Open Source 和 Chroma 都是开源选项；Qdrant Cloud、Weaviate Cloud、Zilliz Cloud、MongoDB Atlas、Redis Cloud、Pinecone 与 Chroma Cloud 则提供免费入门档。即使软件免费，基础设施、备份和工程投入仍然是成本。

最好的开源向量数据库是什么？

Qdrant 是最强的专用开源默认方案，因为它的过滤与混合检索适合许多生产 RAG 系统。如果向量应与关系型应用数据共存，pgvector 更合适；只有确实需要 Milvus 的规模且有能力运维时，才应选 Milvus。

混合搜索该选哪款向量数据库？

Weaviate 是最清晰的托管混合搜索工具链，因为它开放了 BM25F 与向量权重、融合、过滤和加权控制。Qdrant、Pinecone、turbopuffer、Zilliz、pgvector、Elasticsearch、Redis 与 Chroma Cloud 也支持混合模式，但控制界面与运维取舍各不相同。

本地向量数据库选什么？

对许多 RAG 原型而言，Chroma 是最容易上手的本地起点。如果本地应用已经运行 Postgres，pgvector 更合适。本地原型并不能直接决定生产选型，因为权限、恢复、并发与 Cloud-only 功能仍需验证。

pgvector 足以支撑生产级 RAG 吗？

可以，前提是 Postgres 已经保存权威数据，而且带过滤召回率、索引内存、写入负载和查询延迟都在服务指标内。关键测试来自它已记录的过滤行为：近似索引扫描后才执行过滤，因此高选择性条件可能需要迭代扫描或专用引擎。

Pinecone 和 Qdrant 应该怎么选？

如果全托管服务与更低运维负担足以证明按量计费合理，选择 Pinecone。如果开源控制、嵌套过滤或部署灵活性更重要，选择 Qdrant，同时接受自托管工作或基于资源的 Cloud 容量评估。

什么时候该从 pgvector 迁移到专用向量数据库？

只有测量结果表明，经过索引与分区优化后，带过滤召回率、延迟、写入负载、索引内存或数据库隔离仍无法满足明确的生产目标时，才应迁移。单看向量数量，不是负责任的迁移依据。

最终推荐

对数量最多的开发团队而言，pgvector 是最佳向量数据库，因为风险最低的架构通常是一套数据库，而不是两套。带过滤检索迫使架构拆分时，Qdrant 是最佳专用开源升级路径；团队希望花钱免去数据库运维时，Pinecone 是最佳托管升级路径。如果向量本就应该留在已经服务产品的数据平台里，则 Elasticsearch、MongoDB 和 Redis 各有胜场。

一条经得住时间的采购顺序是：先看数据重力，再看带过滤召回率，然后看运维负担，最后才看价格。只有通过前三项约束的系统，才值得进入价格比较。

签年度方案前，先运行一套有代表性的真实负载：使用实际向量维度、最棘手的权限过滤、正常查询速率、峰值摄取突发、删除路径、备份恢复和故障模式。最好的数据库，是能够满足这些服务指标，同时让团队维护系统数量最少的那一个。

获取 AI 业务工作流审计清单

在增加另一套数据库前，梳理数据、权限、同步、交接与运维风险。