谷歌云更新了 AlloyDB 的 ScaNN 索引，官方给出的规模上限是 100 亿向量以上。在这个量级下的实测数据是：P95 延迟不超过 51 毫秒，召回率 95%。AlloyDB 是谷歌云的托管数据库服务，兼容 PostgreSQL 接口。
改动落在索引结构上。此前的 ScaNN 用两层或三层树来组织向量，这次加到了四层。
多一层树，少查两个数量级
近似最近邻检索的做法是先把向量按相似度聚成一层层的簇，查询时从顶层往下走，每层只挑最接近的几个分支展开。层数决定了搜索复杂度：两层树是 O(N^1/2)，三层降到 O(N^1/3)，四层进一步压到 O(N^1/4)。
这几个指数在百亿规模下差得很远。粗算一下，N 取 100 亿时，N 的二分之一次方约等于 10 万，三分之一次方约 2150，四分之一次方约 316。同一个查询要触碰的候选量，从十万级掉到三百级。51 毫秒这个数字就是从这儿来的。
谷歌列出的具体手段包括 Top-K 分支策略、SOAR 算法、质心调整和平衡树构造，另外用动态采样绕开内存限制。官方点名了旧结构的两个卡点：树一大，建索引和查询遍历的计算量都跟着涨；百亿向量做采样时容易吃光可用内存。
是 Agent 把数据量顶上去的
谷歌在文中的说法是，企业级 Agent 应用的需求正在把用例推向数十亿向量，底层向量数据库常常撑不住。
这句话点出了这一轮扩容的来源。传统检索增强场景里，一家公司把内部文档全切成片段，量级通常在千万到亿。Agent 不一样：它每执行一步都要回看历史、查工具说明、翻用户偏好，一次任务下来可能触发十几次检索。数据来源也从文档扩展到会话记录、操作日志、中间产物，这些东西每天都在增量堆积。
再算一笔账。按 51 毫秒的 P95 计，一次 Agent 任务如果走 15 次检索，光在向量库上就要花掉约 0.77 秒。这还只是数据库这一段，模型推理、工具调用、网络往返都得另算。检索延迟在单次交互里看着不起眼，放进多跳链路里就成了体感的一部分。
通用数据库正在收编专用产品
把百亿级向量检索做进 PostgreSQL 兼容的托管服务，指向的是同一条路线：向量不再需要一套单独的基础设施。
对企业客户来说这笔账好算。业务数据本来就在关系库里，用户表、订单表、权限规则都在。向量单独放一套专用库，意味着两套备份、两套权限、两套一致性保证，还得自己处理跨库的事务边界。能在原库里加个索引解决，运维复杂度直接砍掉一半。
专用向量数据库这两年的处境跟着变了。它们在极端性能和检索算法迭代速度上仍有优势，但通用数据库把「够用」的门槛一路抬高——从百万到亿，现在到百亿。留给专用产品的空间，被压到了对延迟和吞吐要求最苛刻的那一小块。
AlloyDB 这次没有公布分区数、向量维度、索引构建耗时和 QPS 上限。这些参数在实际选型里往往比峰值规模更有参考价值，建索引要跑多久尤其关键，百亿量级的重建成本可能高得离谱。
参考来源：谷歌云官方博客、AlloyDB ScaNN 索引文档、CocoLoop；向量规模、P95 延迟与召回率数值以官方公告为准，复杂度换算为编辑粗算。