博客
Turbopuffer vs. Zilliz Cloud：多租户向量检索实测对比

Turbopuffer vs. Zilliz Cloud：多租户向量检索实测对比

2026-03-06

By Fendy Feng, and Yanliang Qiao

Turbopuffer vs. Zilliz Cloud：多租户向量检索实测对比

Serverless 向量数据库的卖点很诱人：零运维、按量付费、没有流量时自动缩容到零。对于要跑多租户 AI 应用的团队来说——RAG、语义搜索、AI 助手——这个方向很难被忽视。成本更低、省去运维、上线更快。

但真正把 Serverless 向量数据库推到生产规模，会发生什么？当你有 12.8 万个租户、真实的过滤条件、真实的删除流程、真实的用户在等结果的时候，它的表现如何？

我们花了 500 美元和两周时间，对 Turbopuffer（S3 存储架构的 Serverless 向量检索方案之一）和 Zilliz Cloud（基于开源 Milvus 构建的企业级向量数据库，支持分层存储）进行了全面的对比评测。

数据相同，Region 相同，客户端硬件相同。1.6 亿个向量。我们测了写入、冷/热查询、全文检索、混合检索、删除、过滤下的搜索准确率、删除后的一致性以及总拥有成本（TCO）。

结论对所有在生产环境选型向量数据库的团队都有参考价值。

测试设计

我们模拟的是一个多租户检索 SaaS——也就是大多数生产级 RAG、语义搜索和 AI 助手背后的架构。租户分三个层级，对应真实世界中的用户分布：

租户类型	数量	每个租户向量数
大客户（核心企业客户）	1	1,600 万
中等客户（标准客户）	16	各 100 万
小客户（长尾/免费用户）	128,000	各 1,000

数据总量：1.6 亿向量，768 维，约 250 GB。

测试环境：两个产品都在 AWS us-west-2（俄勒冈）进行测试。测试客户端：m4.xlarge（4 vCPU，16 GB）。部分测试使用了 m6i.xlarge（8 核）和 16 核客户端。所有 ANN 查询参数：top-k=10，nq=1。全文检索和混合检索测试使用了一个 2000 万行的维基百科数据集。

冷查询测试前不做任何预热，也没有挑配置。

发现一：过滤查询下召回率断崖式下跌

这是整个测试中最严重的发现，而且和性能无关。

在多租户场景下，每次查询都会附带一个过滤条件——通常是租户 ID——来隔离每个客户的数据。这不是边缘情况，这就是多租户向量检索系统的基本工作方式。

我们对 1000 万向量跑了 1000 次 top-100 查询，并在不同的选择率下添加租户过滤条件。结果如下：

过滤选择率	Turbopuffer 召回率	Zilliz Cloud 召回率
宽泛（id > 50%）	0.78	0.99+
中等（id > 90%）	0.69	0.99+
严格（id > 99%，典型小租户）	0.54	0.99+

0.54 的召回率意味着近一半的相关结果被漏掉了——每两条应该出现的结果，就有一条悄无声息地消失了。

根本原因在于架构：Turbopuffer 把过滤当成 ANN 检索的后处理步骤，而不是在构建索引时就感知过滤条件。当过滤条件很严格时——在多租户系统里这几乎是常态——ANN 候选集里包含的匹配文档根本不够，召回率就崩了。

更糟糕的是：

没有调优参数。 没有类似 ef_search 的参数，没有办法扩大候选集，也没有以延迟换精度的配置项。

top-k 有上限。 我们尝试调高 top_k 来多捞一些候选再过滤，结果在允许的最大值 1,200 下，系统只返回了约 500 条结果。这个变通办法本身就是坏的。

静默失败。 Turbopuffer 不会提示召回率低。你的用户只会看到结果变少，你的 RAG 管道会悄悄地只拿到一半的上下文。推荐系统或许还能凑合——用户不知道自己错过了什么。但搜索框或 AI 助手不一样，用户问了一个具体的问题，得到的是残缺的答案，甚至是错误的答案。

这不是性能问题，是正确性问题。向量数据库都给出错误结果了，后面的性能数据也就没什么意义了。

发现二：冷查询延迟——用户真正感受到的响应速度

在任何分层存储的向量数据库里，冷查询——也就是数据不在缓存中时的第一次查询——才是用户实际感受到的延迟。在一个有 12.8 万个租户的系统里，任意时刻大多数查询都是冷的或半冷的。这不是边缘情况，这就是常态。

租户规模	Turbopuffer	Zilliz Cloud	差距
小客户（1K 向量）	206 ms	161 ms	Zilliz 快 22%
中等客户（100 万向量）	1,127 ms	181 ms	Zilliz 快 6.2 倍
大客户（1600 万向量）	2,089 ms	1,021 ms	Zilliz 快 2 倍

Turbopuffer 从小客户到中等客户，冷查询延迟暴涨了 5.5 倍（206 ms → 1,127 ms）。Zilliz Cloud 从 161 ms 增加到 181 ms，几乎感觉不到变化。

对于你最重要的大客户——花钱最多、期望最高的企业用户——Turbopuffer 第一次查询就要等 2 秒。在实时 RAG、客服 Copilot 或搜索驱动的产品功能里，超过 300 ms 用户就会有感知，2 秒已经是无法接受的延迟。

这不是调优能解决的问题，而是 S3 存储架构带来的代价：响应冷查询需要多次 S3 GET 请求（每次首字节延迟 10-100 ms），加上反序列化和重建索引，才能开始第一次搜索。在另一个规模下的独立评测（1000 万向量，代码助手场景）里，我们观察到冷查询 P99 延迟高达 4 秒，且分布很宽，难以预测。

随机租户的额外惩罚

还发现了一个隐藏问题：随机访问不同小租户，比反复访问同一个小租户慢了 100% 以上。

随机小租户平均延迟：232 ms（P99：447 ms）vs. 固定小租户：206 ms。

我们确认 SDK 创建命名空间本身的开销可以忽略（0.002 ms），最可能的原因是多租户场景下的缓存驱逐压力——而这恰恰是 Turbopuffer 主打的使用场景。12.8 万个租户争抢缓存空间，下一个用户查询的那个租户，很可能正是刚被驱逐出去的那个。

发现三：高负载下写入会卡住

正常情况下两个系统的写入吞吐相近：各租户规模均在 5-10 MB/s，成功率 100%。

差距出现在大租户的持续写入压力下。

我们在写入 1600 万向量的大租户数据时，Turbopuffer 三次返回 HTTP 429 进行限流，最长一次停顿了 7 分钟：

12:08:01 - POST id_1600 → 429 Too Many Requests → 60 秒后重试
12:09:02 - POST id_1600 → 429 Too Many Requests → 120 秒后重试
12:11:03 - POST id_1600 → 429 Too Many Requests → 240 秒后重试
12:15:04 - POST id_1600 → 200 OK                ← 7 分钟后才恢复

Turbopuffer 在未索引数据累积到 2 GB 时会触发背压限流。SDK 会自动重试，代码里看不到，但写入管道实际上已经悄悄卡住了。在生产环境的数据同步、实时事件管道或消息队列消费者里，7 分钟的停顿会引发积压、超时报错和数据延迟。

整个测试过程中，Zilliz Cloud 没有出现任何写入阻塞或限流。

发现四：计费陷阱——你算出来的价格和最终账单不是一回事

Turbopuffer 的定价看起来很清晰：按写入量、查询量、存储量计费，没有集群费。计算器简单，估算出来的价格也很吸引人。

我们在测试前用计算器按真实工作负载估算：1000 万向量，768 维，1000 个租户，约 40 QPS。估算结果：每月 220 美元。 对比专用集群 800-1200 美元/月，省了 75%，看起来毫无疑问。

然而，按生产规模实际跑下来：每月 1000 美元以上。

原因在于一个容易被忽视的计费逻辑：queried_bytes 按被查询命名空间的总大小计费，而不是查询实际访问的数据量。每次查询大租户，都按整个命名空间的体积收费，哪怕你只取 top-10。查询大租户的费用是查询小租户的 10 倍——不是因为做了 10 倍的工作，而是计费方式就是这样设计的。

真实的多租户系统中，租户规模呈幂律分布。最大的那些租户产生的查询量不成比例地多，每次查询都按全命名空间费率收费。计算器假设租户大小均匀，根本无法模拟这种情况。

大规模下的成本对比

费用项	Turbopuffer	Zilliz Cloud（分层存储）
写入成本	$1/GB	免费
查询成本	$0.005/GB	免费
存储成本	~$0.40/GB/月	~$0.04/GB/月

以 2 亿文档（约 600 GB）的生产规模来算：

每月存储费用：Turbopuffer 约 195 美元 vs. Zilliz Cloud 约 24 美元，相差 8 倍
每年 1 TB 写入成本：Turbopuffer 1000 美元 vs. Zilliz Cloud 0 美元
本次测试 250 GB 写入成本：Turbopuffer 500.97 美元 vs. Zilliz Cloud 0 美元

Zilliz Cloud 的起点是集群基础费（最低 64 美元/月），比 Turbopuffer 的零起步贵。但一旦有了生产数据和生产查询量，Turbopuffer 的边际成本就会迅速反超。你的产品越成功——写入越多、查询越多——Turbopuffer 的账单增速就越快。Zilliz Cloud 额外写入和查询的边际成本是零。

发现五：删除操作——延迟抖动大、元数据过时、一致性难以保证

延迟抖动

操作	平均延迟	P99	最小	最大	波动倍数
单条记录删除	842 ms	2,716 ms	64 ms	3,280 ms	51x
命名空间删除	183 ms	775 ms	118 ms	5,345 ms	45x

最快和最慢相差 51 倍，根本无法给删除操作设 SLA。对于 GDPR 合规（被遗忘权）、数据生命周期管理，或任何依赖删除操作可预期性的流程，这是一个严重问题。

元数据不会立即更新

删除之后，Turbopuffer 的元数据（行数统计）不会立即更新。我们测到了 30 秒的更新周期——在这段时间里，namespace.meta() 返回的仍是旧数据。如果你的应用靠行数来验证删除是否成功（这是很常见的做法），会拿到错误结果长达半分钟。

删除后一致性问题

在扩展测试中，我们发现了一个更严重的问题。调用 delete_by_filter 后，API 返回成功，已删除的文档也不再出现在结果里。但结果总数是错的——请求 top-100，返回 48 条，然后 64 条，然后 69 条，慢慢爬升，大约一个小时后才稳定到 100 条。

删除把文档从结果里摘掉了（软删除），但没有触发索引重建。底层索引仍反映删除前的状态，慢慢地自行收敛，没有任何通知，没有进度提示，也没有办法强制触发重建。

对于依赖准确结果数量的下游系统——分析管道、数据质量监控、一致性检查——这意味着长达一小时的数据窗口期内，数据是悄悄错误的。

发现六：高并发下触发限流

Turbopuffer 对单个命名空间有并发限制，我们多次碰到：

ANN 查询：对单个小租户 60 并发时开始出现 429。对中等租户 200 并发时，限流非常严重，大量请求失败。
混合检索：大租户并发查询在 30 并发时触发 429。
写入：大租户写入也触发了 429（如发现三所述）。

错误信息：

{
  "error": "Too many concurrent queries to a single namespace.",
  "status": "error"
}

问题在于：流量最高的租户——也就是你最核心的客户——最先触发限流。这个上限无法通过控制台配置或调整。只要有单个租户会产生突发流量（一组用户同时搜索、批处理任务、集成合作方），这就是一个绕不开的硬天花板。

高并发下，我们还观察到 connection reset by peer 和 broken pipe 报错，说明问题不只是限流，而是底层基础设施的容量饱和。

发现七：全文检索和混合检索的稳定性问题

我们用 2000 万行维基百科数据集测试了全文检索和混合检索：

全文检索：冷查询延迟在 640 ms（大租户最佳）到 1,229 ms（中等租户）之间，大租户多次测试平均 1,001 ms。热查询 QPS 表现不错：868-1,688，取决于租户规模。

混合检索的问题更突出：

大租户冷查询延迟：同一查询跑了多次，范围在 718 ms 到 2,446 ms 之间，波动达 3.4 倍
大租户并发查询：仅 30 个并发就触发了 429 限流
小租户和大租户的并发混合检索都出现了查询失败

同一数据上的同一查询，延迟波动 3.4 倍，意味着无法对混合检索设定可靠的 SLA。加上发现一中描述的召回率问题，混合检索在生产环境的就绪度是存疑的。

发现八：企业级能力差距

生产环境里跑一个向量数据库，不只是查询速度的问题。还要看出了问题怎么办，团队能不能看到系统状态，合规审计能不能过，业务对可用性有没有保障。这才是开发工具和生产平台的本质差距所在。

可观测性与监控

能力	Turbopuffer	Zilliz Cloud
性能指标 Dashboard	无	18+ 项指标，实时 Dashboard
自动告警	无	41 条告警规则覆盖 26 项指标（企业版）
查询与操作日志	无	内置，支持审计日志导出
第三方可观测性集成	无	Datadog、Prometheus
自定义告警阈值	无	支持，按组织 / 项目配置

Turbopuffer 的控制台只有四个 Tab：Overview、Namespaces、API Keys、Settings。你能看到汇总的存储量和查询次数，仅此而已。没办法看单个租户的延迟，没办法排查慢查询，没办法对延迟尖刺设告警，也没办法把指标导到你已有的监控体系里。

Zilliz Cloud 提供覆盖 QPS、延迟、吞吐量、CPU、内存、存储的实时 Dashboard，并可以接入 Datadog 或 Prometheus，和你已有的基础设施监控统一管理。凌晨三点某个租户查询开始变慢，告警会在用户发现之前先触发。用 Turbopuffer，你只能等用户提工单。

安全与合规

能力	Turbopuffer	Zilliz Cloud
传输加密	TLS	TLS 1.2+，AES-256
静态数据加密	SSE（S3）	AES-256，支持用户自管密钥
SOC 2 Type II	未公示	已认证
ISO 27001	未公示	已认证
HIPAA 就绪	未公示	支持（Business Critical）
GDPR 就绪	未公示	支持
Private Link（不走公网）	不支持	支持
网络隔离集群	共享基础设施	每个集群独立 VPC

对于医疗、金融、政府或企业 SaaS 团队，合规认证不是加分项，是采购门槛。SOC 2 Type II、ISO 27001、HIPAA 就绪是拿下企业订单的基本条件。Turbopuffer 没有公示任何这些认证。

Private Link 也是很多企业的硬性要求：数据库连接不走公网。Zilliz Cloud 支持，Turbopuffer 不支持。

访问控制与权限管理

能力	Turbopuffer	Zilliz Cloud
API Key 类型	4 级（管理/读写/只写/只读）	细粒度，按集群/Collection 配置
RBAC	无	Collection 级别 RBAC
企业 SSO（SAML/OIDC）	无	Okta、Microsoft Entra 等
审计日志	无	完整操作审计，支持导出到云存储
团队/角色管理	基础	组织 → 项目 → 集群层级管理

Turbopuffer 的访问控制只有四种 API Key 类型。无法限制 Key 只访问特定命名空间，没有企业身份 SSO 对接，没有操作审计追踪。对于超过几个开发者的团队——或者任何有访问治理要求的客户——这意味着你得自己在上层搭一套权限系统。

数据保护与灾难恢复

能力	Turbopuffer	Zilliz Cloud
自动备份	未记录	定期备份，策略可配置
时间点恢复	不支持	支持（Business Critical）
跨 Region 复制	不支持	Global Cluster，基于 CDC 的复制
自动故障转移	不支持	零代码切换到最近健康 Region
多 AZ 部署	未记录	副本自动分布到多个 AZ

Turbopuffer 把数据存在 S3，持久性没问题。但持久性不等于可恢复性。如果一次错误写入损坏了数据，如果批量删除出了问题，如果你需要恢复到某个时间点——目前没有任何文档说明该怎么做。

Zilliz Cloud 的 Global Cluster 通过 CDC 管道实现跨 Region 同步，并支持无需修改代码的自动故障转移。对于业务关键型应用，区别就在于"数据在 S3 上是安全的"和"某个 Region 挂了服务还能继续跑"。

部署灵活性

能力	Turbopuffer	Zilliz Cloud
部署模式	仅 Serverless	Serverless、Dedicated、BYOC
BYOC（自带云）	不支持	AWS、GCP、Azure
基础设施即代码	不支持	官方 Terraform Provider
Region 覆盖	有限	AWS、GCP、Azure 多 Region
可用性 SLA	未公示	99.95%（企业 Dedicated）

Turbopuffer 只有一种部署形态：他们的 Serverless 平台。如果你的安全团队要求基础设施跑在你自己的 VPC 里，如果你的合规框架对数据驻留有要求，如果你需要一个写进客户合同的 SLA——Turbopuffer 都满足不了。

Zilliz Cloud 提供带 99.95% SLA 的 Dedicated 集群、支持在你自己的 AWS/GCP/Azure VPC 内部署的 BYOC 模式，以及面向 IaC 工作流的 Terraform Provider。这些不是加分功能，是企业采购核查表上的必选项。

生态集成

能力	Turbopuffer	Zilliz Cloud
AI 框架集成	有限	LangChain、LlamaIndex、Haystack、DSPy
数据管道连接器	无	Kafka、Spark、Airbyte、Fivetran
迁移工具	无	VTS（开源）、托管迁移服务
云市场上线	未列出	AWS、GCP、Azure 市场均有

生产级 AI 应用不是孤岛，它嵌在整个数据管道里——Kafka 做流式接入，Spark 做批处理，Airflow 做调度，LangChain 或 LlamaIndex 跑 RAG。Zilliz Cloud 对这些都有原生连接器，Turbopuffer 需要全部手写集成代码，增加了大量开发和维护成本。

如果你需要从其他向量数据库迁过来，Zilliz Cloud 的 Vector Transport Service 支持从 Elasticsearch、OpenSearch、Pinecone、Qdrant、Weaviate 和 PostgreSQL 迁移，Milvus 源还支持零停机迁移。用 Turbopuffer，迁移就是应用层的手工活儿。

总结

对比维度	Turbopuffer	Zilliz Cloud
过滤下搜索召回率	0.54 — 漏掉近一半相关结果	0.99+
中等客户冷查询延迟	1,127 ms	181 ms
大客户冷查询延迟	2,089 ms（P99 可达 4s）	1,021 ms
写入稳定性	被限流 3 次，最长停 7 分钟	无中断
600 GB 存储成本	存储贵 8 倍；写入/查询额外计费	写入/查询免费
删除延迟波动	51x（64 ms – 3,280 ms）	可预期
删除后一致性	约 1 小时才收敛	即时
并发限流	单命名空间硬上限，不可调	可配置
运维工具	极为有限	完整监控、日志、告警