Google boosts AlloyDB vector search with HNSW preview

Google has introduced columnar engine-accelerated HNSW for AlloyDB in preview, saying the feature can increase vector search throughput by up to four times.

The update targets pgvector users, the PostgreSQL extension commonly used to store, index and query vector embeddings for artificial intelligence applications. It is aimed at teams running approximate nearest neighbour searches with HNSW, or Hierarchical Navigable Small World, across very large datasets.

AlloyDB is Google's managed PostgreSQL-compatible database service. The new option uses AlloyDB's columnar engine, an in-memory cache that stores frequently queried data in a column-based format, to keep HNSW indexes in memory and avoid some of the overhead of standard PostgreSQL buffer management.

Google said this improves both throughput and recall, the measure of how many relevant matches a search returns. In benchmark testing on the GloVe 100 Angular dataset across more than 1 million records, with a search limit of 100, queries per second rose by about 4.2x to 4.9x at a target recall of 0.95.

At the same throughput level, recall also improved. At about 350 queries per second, recall increased from roughly 0.78 to more than 0.94, a gain of 0.163, when the columnar engine setting was enabled.

How it works

Standard PostgreSQL relies on a shared buffer cache for index operations, even when data is already in memory. That process still involves page pinning and unpinning, lock handling, buffer table lookups and least recently used management, which can add latency and reduce efficiency during graph traversal.

AlloyDB changes that path by pinning the pgvector HNSW index directly into the columnar engine's memory space. It also uses a memory layout designed for the pointer-heavy traversal patterns HNSW requires, bypassing the usual buffer manager bottlenecks.

Google said the improvement does not come simply from moving data from disk into RAM. The baseline comparison already assumed the standard PostgreSQL index was fully cached in shared buffers, meaning the reported gains came from a different memory architecture rather than basic caching.

The launch reflects growing pressure on database suppliers to support retrieval-augmented generation and other AI workloads that depend on vector search. In those systems, operators often have to balance speed against accuracy when searching millions or billions of vectors, especially under production traffic.

For PostgreSQL users, pgvector has become one of the most widely used tools in this area because it allows vector functions to run inside an established relational database stack. HNSW is a popular indexing method within pgvector because it offers approximate search with lower latency than exact k-nearest neighbour methods, although operators usually accept some trade-off in recall.

Google is positioning AlloyDB as a database that can handle relational transactions, analytics and vector search in one system. Alongside HNSW, the service also supports ScaNN, another vector index option, while standard k-nearest neighbour search remains available for users that need full recall.

Operational trade-offs

The columnar engine uses memory, which remains a practical consideration for database operators managing costs and instance sizing. Google said the memory footprint is limited because the engine stores vector data in a compressed columnar format.

Google argued that the trade-off could reduce infrastructure needs by allowing users to achieve a given level of vector search performance with less compute. It also said the feature does not require changes to application code, because users can continue to work with standard pgvector SQL syntax.

To use the feature, AlloyDB users must enable both the columnar engine and index caching flags on their instance. After creating an HNSW index through pgvector, they then add that index to the columnar engine cache with a SQL command.

The rollout gives Google another way to differentiate AlloyDB in the growing market for databases adapted to AI workloads, where cloud providers and specialist database groups are competing on throughput, latency and search quality rather than storage alone. The benchmark Google cited was run on an AlloyDB C4A machine with 16 virtual CPUs.