Google Cloud has updated the ScaNN index in AlloyDB, and the company now states an official scaling ceiling of more than 10 billion vectors. At that scale, its benchmark numbers show P95 latency under 51 milliseconds with 95% recall. AlloyDB is Google Cloud's managed database service, compatible with the PostgreSQL interface.
The change sits in the index structure itself. ScaNN previously organized vectors using a two- or three-layer tree; this update adds a fourth layer.
One more tree layer, two orders of magnitude fewer lookups
Approximate nearest neighbor search works by clustering vectors into layers of groups based on similarity, then walking from the top layer downward at query time, expanding only the closest branches at each level. The number of layers determines search complexity: a two-layer tree runs at roughly O(N^1/2), a three-layer tree drops to O(N^1/3), and a four-layer tree compresses that further to O(N^1/4).
At the 10-billion scale, those exponents diverge sharply. Rough math: with N at 10 billion, the square root is about 100,000, the cube root is about 2,150, and the fourth root is about 316. The number of candidates a single query has to touch falls from the hundred-thousand range down to roughly 300. That's where the 51-millisecond figure comes from.
Google lists several specific techniques behind the gains, including a Top-K branching strategy, the SOAR algorithm, centroid adjustment, and balanced tree construction, along with dynamic sampling to work around memory limits. The company names two specific bottlenecks in the older structure: as a tree grows, both index-building and query-traversal compute rise with it; and sampling across 10 billion vectors tends to exhaust available memory.
Agents are what pushed the data volume up
Google's own framing is that enterprise agent applications are pushing use cases toward billions of vectors, and that the underlying vector databases often can't keep up.
That line points to where this round of scaling actually comes from. In a traditional retrieval-augmented generation setup, a company chops its internal documents into chunks, typically landing somewhere between tens of millions and a few hundred million vectors. Agents are different: each step they take may involve looking back at history, checking a tool's documentation, or pulling up user preferences — a single task can trigger a dozen or more retrieval calls. The data sources have also expanded beyond documents to session records, operation logs, and intermediate outputs, all of which accumulate incrementally every day.
Do the math further. At a 51-millisecond P95, an agent task that runs 15 retrieval calls spends roughly 0.77 seconds on the vector database alone — and that's before counting model inference, tool calls, or network round trips. Retrieval latency looks trivial in a single interaction, but stacked across a multi-hop chain it becomes part of what users actually feel.
General-purpose databases are absorbing specialized products
Building 10-billion-scale vector search into a PostgreSQL-compatible managed service points to the same underlying trend: vectors no longer need a dedicated piece of infrastructure of their own.
For enterprise customers, the math is straightforward. Business data already lives in a relational database — user tables, order tables, permission rules. Putting vectors in a separate specialized database means maintaining two backup systems, two permission models, two consistency guarantees, and handling transaction boundaries across databases on your own. Being able to just add an index to the existing database cuts that operational complexity roughly in half.
The position of dedicated vector databases has shifted over the past couple of years as a result. They still hold an edge in extreme performance and in how fast they can iterate on retrieval algorithms, but general-purpose databases keep raising the bar on what counts as "good enough" — from millions, to hundreds of millions, and now to billions. The room left for specialized products has been squeezed down to the narrow slice of workloads with the strictest latency and throughput demands.
AlloyDB didn't disclose partition counts, vector dimensions, index build time, or a QPS ceiling this time around. Those figures often matter more in real-world evaluation than peak scale numbers do — build time in particular, since the cost of rebuilding an index at the 10-billion scale could turn out to be steep.
Sources: Google Cloud official blog, AlloyDB ScaNN index documentation, CocoLoop; vector scale, P95 latency, and recall figures are as stated in the official announcement, and complexity calculations are editorial estimates.