Pinecone 替代方案：选项对比

我们的利害可以忽略，声明只是走形式：我们是 Geonode，销售代理，与这一切毫无关系。无论你选哪个选项，我们都没有任何收益，在这个类别里这种立场本该更常见——这类对比大多由被比较的厂商之一发布。以下每个数字都来自厂商自己的定价页或仓库，于 2026 年 9 月核对，许可证来自项目自己的仓库，而不是营销页。

四类，而非一类

比较产品之前，先弄清你在买哪一类。它们不能互相替代。

托管向量数据库。 Pinecone、Qdrant Cloud、Weaviate Cloud、Zilliz Cloud、Chroma Cloud。你发送数据和查询；别人运行索引。适合规模、多租户，以及不愿运营分布式基础设施的团队。

自托管向量数据库。 Qdrant、Weaviate、Milvus、Chroma——四个都是开源，可在自有硬件上运行。适合数据驻留要求、规模化后可预期的成本，以及已经在运营基础设施的组织。

已有数据库上的扩展。 pgvector 为 Postgres 增加向量相似度搜索。适合非常常见的情况：你已经在跑 Postgres，再加第二个数据存储才是昂贵的部分。

不用数据库。 内存数组，或嵌入式库。适合小语料，而小语料比人们预想的多。

本文其余部分顺着这个清单往下走。

托管选项

价格来自各厂商自己的定价页，于 2026 年 9 月核对。做预算前请再核实——这一类经常改价。

把这些行对照着读很有启发，因为计费单位不可比。

Pinecone 按读写 units 计费。Weaviate 按百万 向量维度 计费，所以同一条记录，1536 维嵌入的成本是 768 维的两倍——模型选择直接变成成本决策。Chroma 按写入的 GiB 和查询的 TiB 计费。Qdrant 按预配资源计费。

无法用头条费率比较这些。唯一有意义的比较是用你自己的负载——记录数、维数、查询量、存储——对照每家定价计算器去建模。这是一小时的工作，并且经常因负载形状不同而产生任一方向上数量级的差异。

两条值得抽出的结构性说明。

Weaviate 的免费档对评估确实慷慨——100,000 个对象，"always free"，每用户一个集群——其按维度计费也会以其他家没有的方式奖励更小的嵌入模型。

Chroma 的 Team 方案起价 $250/月 外加用量，门槛明显高于其他。Starter 方案是 $0/月加用量，含 $5 额度，所以入门很轻，往上跨的那一步则不轻。

自托管选项

四大开源向量数据库都是真正的开源，许可证差异对商业使用有影响。这些来自项目自己的仓库，于 2026 年 9 月核对。

四个都是宽松许可，这才是要点：没有一个带 copyleft 或使用领域限制，以免把商业产品搞复杂。值得说清楚，因为数据库世界里并非普遍如此，也因为许可证检查是那种被跳过、然后在最糟时刻变成问题的事。

在它们之间选择，简短而诚实：

Qdrant 是你只想要一个自托管向量数据库、别的都不要时，该先试的那个。单一二进制、Rust、运维直截、资源占用小。

Milvus 为分发和大规模而建，架构相应地更重——多个组件、消息队列、对象存储。在规模上强大，规模之下开销可观。

Chroma 最容易上手。开发时在进程内运行，让第一个小时变得琐碎简单，并可扩展到服务器部署。

Weaviate 在数据库本身周围功能集最丰富——嵌入、重排序和生成式搜索模块——要么正是你要的，要么超出你需要的。

诚实的总结是：自托管部署在几千万向量以下，四个都管用，差异是运维上的而非根本性的，决定因素通常是你的团队能舒适地跑哪一个。

pgvector：被低估的答案

比任何专用向量数据库都适合更多项目的选项，却最不受关注。

pgvector 是为 Postgres 增加向量类型和相似度搜索的扩展。它开源、部署广泛，并且在各大云的 Postgres 服务上都有托管产品——因此对很大一部分团队，完全不需要新基础设施。

优势是结构性的，不是技术性的：

一个数据库而不是两个。 向量与关系数据住在一起，同一事务、同一备份、同一访问控制和同一监控。这份运维节省比听起来更大。

Join 能用。 用关系 schema 里的任何东西过滤向量结果，是一条 WHERE 子句，而不是自带语义和限制的元数据过滤功能。

没有额外账单，如果你已经在跑 Postgres。

一致性是免费的。 在一笔事务里写入记录及其嵌入，消除了每个双数据库架构都存在的一整类同步 bug。

限制是真实的，值得知道：

规模。 它能很好地处理数百万向量，并非为数十亿设计。交叉点取决于查询模式和硬件，而且比舆论暗示的更高。

近似索引的构建时间和内存 在规模上需要关注，调优是 Postgres 管理任务，而不是托管服务操心的事。

检索专用功能更少。 没有内置重排序、没有托管嵌入模型，混合搜索也不如专用系统精巧——不过 Postgres 全文搜索覆盖了其中很大一块。

经验法则：如果你已经在跑 Postgres，并且向量不到几百万，从这里开始。 以后超出了可以再迁到专用系统，而大多数项目不会超出。

完全不用数据库

不花一分钱、却比任何人都承认的更经常正确的选项。

大约十万向量以下，暴力相似度搜索在普通硬件上已经够快。对 100,000 × 768 矩阵做一次查询点积，就是一次矩阵乘法——笔记本上毫秒级，而且是精确的而非近似的：

import numpy as np

scores = embeddings @ query          # embeddings: (n, d), query: (d,)
top = np.argsort(-scores)[:10]

这就是全部实现。没有服务、没有索引构建、没有账单、没有网络跳、没有近似误差。

嵌入式库 把同一想法往前推。FAISS 及类似库在单进程里用近似索引处理数百万向量，给你向量数据库的大部分性能，却不用运营一个。

何时不再管用： 数据不再装得进内存，需要多个进程并发写入，需要多租户隔离，或查询量要求水平扩展。这些是真实门槛，而且来得比人们预期的晚。

这之所以重要不是为了纯粹，而是为了诊断。从最简单的东西开始，意味着检索质量差时——一开始通常就是差的——你知道原因不是数据库。分块策略、嵌入模型选择和查询表述主导检索质量，这些都不会因为托管服务而变好。

真正的差异在哪里

这一类的功能表又长又大多无关，因为每个产品都把向量相似度搜索做得够用。真正不同的有五件事，值得对照你的需求去查。

混合搜索，以及它如何表达。 把语义相似度与精确关键词匹配结合起来，能挽救标识符、产品代码和罕见专有名词上的检索——纯向量搜索在这些地方出了名地弱。现在每个系统都支持某种形式，实现差异很大：有的跑你必须维护的单独稀疏索引，有的在声明的文本字段上提供 BM25，有的指望你自己融合两套结果。如果语料里有任何像代码的东西，专门测这个，而不是相信一个复选框。

元数据过滤语义。 它们都会按元数据过滤；问题是过滤发生在近似搜索之前还是之后，以及这对结果做什么。对 top-k 结果集做后过滤，在过滤器很挑的时候可能返回不足 k 条——或一条都没有——这是生产查询第一次碰上时会吃惊的失败。预过滤能避免它，代价更高。弄清你拿到的是哪一种。

多租户模型。 Namespaces、collections、每租户索引，或一个元数据字段。隔离保证很不同，高租户数下的性能特征也很不同。如果你为许多客户构建，这是以后最难改的决定。

更新和删除行为。 有的系统能体面地处理频繁更新；有的堆积 tombstones，需要周期性压缩，影响查询延迟。如果你的数据不断变化——而不是加载一次再读——要明确问这个，因为它很少出现在对比页上，却主导运维体验。

写入后的一致性。 记录 upsert 后是立即可搜索，还是最终一致。最终一致对文档语料完全合理，对用户自己的数据在创建几秒后出现在自己的搜索结果里则相当不合理。

这些都不出现在定价表里，都可以在免费档测试，任何一件都可能是纸面上看起来完美的系统并不合适的原因。

如何选择

一套决策流程，而不是功能矩阵。

先在本地测量检索质量。 建一个小评测集——二十或三十个有已知正确答案的问题——用内存实现对它测试分块和嵌入选择。这花一天，对结果的决定作用大于之后任何选择。

然后数你的向量。 十万以下，留在内存。已经在跑 Postgres 且不到几百万，用 pgvector。再往上，或多租户、或高查询量，再看专用系统。

然后决定托管还是自托管。 如果你不愿运营分布式索引且成本可接受，选托管。如果你有数据驻留要求、可预期的大规模用量，或已有基础设施能力，选自托管。

然后用你的实际负载建模成本，因为计费单位不可比，这里的直觉一文不值。按维度、按单位、按资源的定价，对同一应用给出非常不同的答案。

提交前检查迁移路径。 向量是可移植的——它们只是数字——周围的功能不是。元数据过滤语法、混合搜索配置和 namespace 模型都不同，所以搬家的成本在应用代码里，不在数据里。保住源文档和分块流水线，会让未来任何搬家成为重建，而不是导出。

常见问题

最好的 Pinecone 替代方案是什么？

没有单一答案，因为类别不同。如果你已经在跑 Postgres 且向量几百万或更少，用 pgvector。如果你想要直截了当的自托管向量数据库，用 Qdrant。如果你想要托管且他们的定价模型适合你的负载形状，用 Weaviate Cloud 或 Chroma Cloud。

有没有免费的 Pinecone 替代？

有好几个。四大开源向量数据库——Qdrant、Milvus、Chroma 和 Weaviate——都是宽松许可、可免费自托管。pgvector 免费，跑在你可能已有的 Postgres 上。大约十万向量以下，内存 NumPy 实现完全不花钱。

pgvector 足以替代向量数据库吗？

对大量应用，是的。它处理数百万向量，把嵌入放在与关系数据同一事务和备份里，并能用普通 SQL join 过滤。它不是为数十亿向量设计的，检索专用功能也更少，这正是专用系统赢得位置的地方。

哪个向量数据库最便宜？

没有你的负载就无法回答，因为计费单位根本不同——Pinecone 按读写 units、Weaviate 按百万向量维度、Chroma 按写入 GiB 和查询 TiB、Qdrant 按预配资源。用自己的数字对照每家计算器建模。

开源向量数据库生产可用吗？

Qdrant、Milvus、Weaviate 和 Chroma 都在积极开发、宽松许可，并在生产中广泛部署。问题不是它们能不能用，而是你想不想运营它们——这正是各家托管版在卖的东西。

开源向量数据库用什么许可证？

Qdrant、Milvus 和 Chroma 是 Apache-2.0；Weaviate 核心是 BSD-3-Clause。都宽松，无 copyleft 或使用领域限制，不过有的厂商对特定企业模块单独授权，如果你依赖其中一个，值得核对。

RAG 一定需要向量数据库吗？

不一定。检索质量由分块策略、嵌入模型选择和查询表述主导，这些都不是数据库能改善的。先用内存实现构建和评估；当语料规模或查询量真正需要时再加基础设施。

在向量数据库之间迁移有多难？

向量很容易搬——它们是数字数组。难点在应用代码，因为元数据过滤语法、混合搜索配置和多租户模型都不同。保住源文档和分块流水线，会让迁移成为重建，而不是导出。

总结

关于这一类最有用的认知是：选择是在四种东西之间，而不是在五个产品之间。托管服务、自托管数据库、你已经在跑的数据库上的扩展，以及什么都不用。

对很大一部分项目，答案是后两种之一。pgvector 在你已经运营的基础设施里处理数百万向量，带有外部服务给不了的事务一致性和 SQL join。大约十万向量以下，内存里的一次矩阵乘法精确、即时、免费。

在专用系统有必要的地方，开源选项都宽松许可、真正达到生产级——Qdrant、Milvus 和 Chroma 是 Apache-2.0，Weaviate 是 BSD-3-Clause——所以自托管是真正的选择，而不是妥协。若你想托管，用自己的负载对照各厂商计算器建模，因为计费单位不可比，同一应用在它们之间可以差一个数量级。

无论选什么，先在本地做检索质量工作。让检索系统好坏的很少是数据库，签完合同才发现这一点，是昂贵的走法。