# Supercharging pgvector: 4x faster HNSW vector search with AlloyDB > Source: > Published: 2026-07-21 16:00:00+00:00 [AlloyDB](https://cloud.google.com/alloydb) is a fully managed, PostgreSQL-compatible database service built for your most demanding enterprise workloads. It combines the best of open source PostgreSQL with Google’s advanced technology, offering massive scalability, high availability, and native AI capabilities. It serves as a performant relational store, a unified backend for vector and full text search, and an analytics engine that is up to 100x faster than standard PostgreSQL. Vector search is the foundation of modern AI and Retrieval Augmented Generation (RAG) applications. For developers using AlloyDB and other PostgreSQL databases, [ pgvector](https://github.com/pgvector/pgvector) is a widely adopted extension for storing, indexing, and querying vector embeddings, and HNSW (Hierarchical Navigable Small World) is a highly efficient graph-based algorithm designed for approximate nearest neighbor search across multi-layered structures. With Enterprise AI applications face a constant trade-off between speed and accuracy. When searching through millions or billions of vectors, maximizing Queries per Second (QPS) without sacrificing search quality (recall) is critical for scaling production workloads. The PostgreSQL `pgvector` extension offers HNSW as one of the indexes that can speed up Approximate Nearest Neighbor (ANN) searches. Let’s dive deep into how AlloyDB solves the speed vs. accuracy trade-off. Note: While this post focuses on HNSW performance, it’s worth noting that HNSW is just one part of AlloyDB’s advanced vector toolkit. AlloyDB also features [ScaNN](https://docs.cloud.google.com/alloydb/docs/ai/create-scann-index)—a cutting-edge index backed by over 14 years of Google Research—giving you the flexibility to choose the perfect index for your workload. Additionally, for use cases demanding absolute precision, standard k-nearest neighbor (KNN) search is always available for 100% recall. Check out our [Choose a Vector Index Guide](https://docs.cloud.google.com/alloydb/docs/ai/choose-index-strategy) to see how they stack up. The [AlloyDB columnar engine](https://docs.cloud.google.com/alloydb/docs/columnar-engine/about) is a built-in, in-memory cache that automatically stores frequently queried data in a specialized, scan-optimized columnar format. It allows AlloyDB to handle heavy analytical queries up to 100x faster than standard PostgreSQL. Additionally, it accelerates ANN searches by storing the index in memory, using a vectorized memory layout for fast traversals, and bypassing standard PostgreSQL buffer manager overhead. To understand the real-world performance characteristics of columnar engine Accelerated HNSW, we plotted standard QPS vs Recall curves for the GloVe 100 Angular dataset by searching more than 1M records with a limit of 100. Running this [benchmark script](https://colab.research.google.com/github/GoogleCloudPlatform/python-docs-samples/blob/main/alloydb/notebooks/columnar_engine_accelerated_hnsw_vector_search_benchmark.ipynb) yields the following visualization: The data reveals two transformative benefits: 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. 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: `pgvector` HNSW index is pinned (kept persistently in-memory to ensure fast access) directly into the columnar engine’s memory.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. To try out [ columnar engine accelerated HNSW](https://docs.cloud.google.com/alloydb/docs/ai/accelerate-with-ce) in AlloyDB, follow these steps: Ensure that both `google_columnar_engine.enabled` and `google_columnar_engine.enable_index_caching` flags are set to `on` for your AlloyDB instance. Once your HNSW index is created via `pgvector` , execute the following SQL command to cache it in the columnar engine: New to AlloyDB? Discover AlloyDB with a [30-day free trial](https://docs.cloud.google.com/alloydb/docs/free-trial-cluster). [Google Colab Notebook](https://colab.research.google.com/github/GoogleCloudPlatform/python-docs-samples/blob/main/alloydb/notebooks/columnar_engine_accelerated_hnsw_vector_search_benchmark.ipynb): An end-to-end Python script to ingest the GloVe dataset, create indexes, and plot Recall vs QPS curves. Is HNSW the right vector index choice for your use case? Check our ‘[Choose a vector index in AlloyDB AI](https://docs.cloud.google.com/alloydb/docs/ai/choose-index-strategy)’ guide.