Google AlloyDB ScaNN Scales Vector Search to 10 Billion Vectors

AlloyDB Introduces Four-Level ScaNN Tree for 10 Billion-Vector Search

Google has announced a new four-level tree architecture for the ScaNN index in AlloyDB, designed to address the compute and memory challenges associated with extremely large vector-search workloads.

The new four-level tree is available in preview and enables AlloyDB ScaNN to operate at a scale of 10 billion vectors. In Google's internal tests, AlloyDB achieved 95% recall with p95 latency of 51 milliseconds or less at that scale.

The development targets enterprise workloads, including agentic AI applications, where vector databases may need to search across billions of embeddings.

The key architectural change is the move beyond the previous two-level and three-level ScaNN tree configurations to a four-level hierarchy.

Why 10 Billion Vectors Creates a Scaling Challenge

Vector search becomes increasingly demanding as datasets grow.

Google says previous AlloyDB ScaNN tree configurations were based on two-level or three-level structures. Scaling these configurations to 10 billion vectors introduced two major challenges.

Higher compute requirements

Larger tree structures can require significantly more operations during both index construction and query traversal.

Memory constraints

Sampling used during index construction can exceed available system memory when working with datasets at this scale.

The new four-level architecture is designed to address both challenges through deeper hierarchical partitioning and more efficient memory use.

How the Four-Level ScaNN Architecture Works

The new architecture uses a top-down hierarchical approach to divide the vector space into increasingly refined partitions.

Instead of searching across a large portion of the dataset directly, each additional tree level narrows the search area.

Google describes the progression as follows:

• Two-level tree: Search complexity of approximately O(N1/2)

• Three-level tree: Search complexity of approximately O(N1/3)

• Four-level tree: Search complexity of approximately O(N1/4)

The four-level design therefore creates more granular partitions, allowing the search process to focus on a smaller portion of the overall vector space.

Hierarchical Partitioning Reduces Search Work

The primary benefit of the four-level structure is hierarchical partitioning.

At each stage, the search is narrowed to a smaller region instead of considering the entire dataset equally.

Google says the architecture incorporates several techniques to maintain performance and help mitigate recall loss, including:

• Top-K branch

• SOAR

• Centroid adjustment

• Balanced tree shape

These components work alongside the four-level architecture to balance search accuracy and index-building efficiency.

The deeper hierarchy is particularly important as datasets expand because it allows the search structure to become more granular.

Memory Efficiency Is Another Key Part of the Design

Processing 10 billion vectors also creates significant memory requirements during index construction.

Google's approach includes two important strategies.

Balanced tree construction

The four-level tree uses a balanced configuration intended to work around memory limitations that can restrict the size of training datasets.

According to Google, this allows reduced sampling sizes to be used while still constructing high-fidelity tree partitions.

Sampling optimization

When memory becomes a constraint, AlloyDB can generate a condensed sampling set designed to balance performance and accuracy.

Together, these approaches help the ScaNN index handle extremely large vector datasets without requiring the complete dataset to be used in the same way during every stage of index construction.

Google's Internal Test Results

Google reports the following results from its internal testing:

The reported results are specifically based on Google's internal tests. They should therefore be understood as source-reported performance rather than a universal benchmark for every AlloyDB deployment.

What the Four-Level Tree Means for Enterprise Vector Search

The development addresses an important challenge for AI systems that rely on vector search.

Modern AI applications can use vector databases to search large collections of embeddings. As the number of vectors increases, index architecture becomes increasingly important because search operations need to balance speed, memory consumption and retrieval accuracy.

Google's four-level ScaNN architecture is designed around that trade-off.

The announcement does not claim that every workload will achieve the reported 51 ms p95 latency or 95% recall. The published results come from Google's internal testing at the 10 billion-vector scale.

For organizations evaluating large-scale vector search, the announcement highlights the importance of:

• Hierarchical index design

• Efficient memory management

• Search-space reduction

• Recall preservation

• Scaling index structures as datasets grow

ScaNN Four-Level Tree Is Available in Preview

The four-level tree architecture is currently available as a preview in AlloyDB.

Google directs users to its ScaNN documentation for configuration and deployment guidance.

The company also provides a quickstart for setting up an AlloyDB instance and testing ScaNN-based vector search.

The Broader Significance

The announcement highlights a broader industry shift toward infrastructure capable of supporting increasingly large AI workloads.

For vector databases, scaling is not simply a matter of storing more embeddings. Index structures also need to manage the computational and memory requirements involved in searching and building those indexes.

AlloyDB's four-level ScaNN architecture addresses this challenge through deeper hierarchical partitioning, balanced tree construction and optimized sampling.

The reported 10 billion-vector scale demonstrates the level of dataset size Google is targeting with the new architecture.

However, organizations should evaluate performance against their own vector dimensions, workloads, recall requirements and infrastructure configurations before drawing conclusions about production performance.