en.Wedoany.com Reported - Google has introduced a columnar engine-accelerated HNSW feature for AlloyDB in preview, claiming it can increase vector search throughput by up to four times.
AlloyDB is Google's managed PostgreSQL-compatible database service. This new option targets pgvector users—a PostgreSQL extension for storing, indexing, and querying artificial intelligence vector embeddings—particularly teams using HNSW (Hierarchical Navigable Small World) to run approximate nearest neighbor searches on extremely large datasets.
The new option leverages AlloyDB's columnar engine—an in-memory cache that stores frequently queried data in a columnar format—to keep HNSW indexes in memory, thereby avoiding some overhead of standard PostgreSQL buffer management. Google says this improves throughput and recall (a metric measuring the number of relevant matches in search results). In benchmarks on the GloVe 100 Angular dataset containing over 1 million records, queries per second increased by approximately 4.2x to 4.9x when the search limit was set to 100 and the target recall was 0.95. At the same throughput level, recall also improved: at approximately 350 queries per second, recall increased from about 0.78 to over 0.94 with the columnar engine enabled, a gain of 0.163.
In terms of how it works, standard PostgreSQL relies on a shared buffer cache for index operations, even when data is already in memory. This 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 this path by pinning the pgvector HNSW index directly into the columnar engine's memory space, employing a memory layout designed for the heavy pointer traversal patterns required by HNSW, bypassing common buffer manager bottlenecks. Google notes that this improvement does not simply come from moving data from disk to RAM; the baseline comparison already assumes standard PostgreSQL indexes are fully cached in the shared buffer, meaning the reported performance gains stem from a different memory architecture rather than basic caching.
This release reflects growing pressure on database vendors to support retrieval-augmented generation and other AI workloads that rely on vector search. In these systems, operators often need to balance speed and 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 space because it allows vector functions to run within an existing relational database stack. HNSW is a popular indexing method in pgvector because it provides approximate search with lower latency than exact k-nearest neighbor methods, although operators typically make some trade-offs in recall.
Google positions AlloyDB as a database capable of handling relational transactions, analytics, and vector search within a single system. In addition to HNSW, the service also supports ScaNN (another vector index option), while standard k-nearest neighbor search remains available for users requiring full recall.
In terms of operational trade-offs, the columnar engine uses memory, which remains a practical consideration for database operators managing costs and instance sizes. Google says that because the engine stores vector data in a compressed columnar format, memory footprint is limited. Google believes this trade-off can reduce infrastructure requirements by achieving a given level of vector search performance with fewer compute resources. The feature does not require changes to application code, as users can continue using standard pgvector SQL syntax. To use the feature, AlloyDB users must enable the columnar engine and index cache flags on their instances, create an HNSW index via pgvector, and then add the index to the columnar engine cache using an SQL command.
This release provides Google with another way to differentiate AlloyDB in the growing market for databases adapted to AI workloads, where cloud providers and specialized database teams compete on throughput, latency, and search quality. The benchmarks cited by Google were run on AlloyDB C4A machines with 16 virtual CPUs.
