The data reveals two transformative benefits:
- Massive performance throughput gains: For any given target recall (e.g. 0.95), QPS is increased by approximately 4.2x to 4.9x. This allows you to handle significantly more concurrent vector searches on the same hardware.
- Significant recall (accuracy) improvement: Conversely, at a fixed QPS level, columnar engine accelerated HNSW provides a substantial boost in recall. For example, we saw that at ~350 QPS (in the above chart), enabling the columnar engine improves recall from roughly 0.78 to over 0.94 – a 0.163 recall gain. This means your AI applications get much more accurate results without any latency impact.
It is important to note that the baseline (blue line) already represents the index being fully cached in the PostgreSQL shared buffer cache. The performance gains shown here are not the result of moving data from disk to RAM, but rather the result of a more efficient memory architecture.
How it works: Columnar engine Accelerated HNSW
In standard PostgreSQL architectures, index operations utilize the shared buffer cache. Even when data is fully in-memory, the database still incurs significant overhead from the buffer manager, which must handle operations such as page pinning and unpinning, lock acquisition, buffer table lookups, and Least Recently Used (LRU) management.
AlloyDB’s columnar engine is a built-in, in-memory cache that stores data in a specialized, scan-optimized format.
With this release, AlloyDB can use columnar engine accelerated HNSW to:
- Pin the index: The pgvector HNSW index is pinned (kept persistently in-memory to ensure fast access) directly into the columnar engine’s memory.
- Vectorized access: It utilizes a memory layout specifically designed for the high-concurrency, pointer-heavy traversals required by HNSW graphs.
- Bypass buffer overhead: By navigating the graph in a specialized memory space, AlloyDB avoids the standard buffer manager bottlenecks. This architectural shift is what enables the dramatic QPS and recall improvements shown above, even when comparing against a fully-cached standard index.
Why it Matters
For enterprise-scale applications, this isn’t just about a faster database—it’s about cost and quality:
-
Reduced infrastructure costs: Achieve the same performance with significantly lower compute resources.
-
Better AI accuracy: Reach higher recall and quality at speeds that were previously only possible for “draft” (high-speed, lower-accuracy results) quality search.
-
No application changes required: Because this is built into AlloyDB, you get these gains using the same standard pgvector SQL syntax.
Note that the columnar engine does utilize memory, but it is highly compressed and meticulously managed. Because the engine stores vector data in an efficient columnar format, the memory footprint is minimal compared to the massive performance gains—making it a highly favorable trade-off for enterprise workloads.
Quick Start Guide
To try out columnar engine accelerated HNSW in AlloyDB, follow these steps:
1. Enable the columnar engine and index caching
Ensure that both google_columnar_engine.enabled and google_columnar_engine.enable_index_caching flags are set to on for your AlloyDB instance.
2. Add the HNSW Index to columnar engine
Once your HNSW index is created via pgvector, execute the following SQL command to cache it in the columnar engine:
