Pg_vectorsearch: An Index Faster Than pgvector's IVFFlat and HNSW

pgvector's Performance Bottleneck and a New Alternative

In the PostgreSQL ecosystem, pgvector has become the de facto standard for vector retrieval. It offers two index types—IVFFlat and HNSW—each targeting different recall-versus-speed tradeoffs. But as vector datasets scale from millions to hundreds of millions of entries, many teams are starting to hit sharply rising query latency and painfully long index build times.

The Pg_vectorsearch project, which recently sparked discussion on Hacker News, is a new index implementation aimed squarely at this pain point. According to the project author, its core goal is to push query speed well beyond what pgvector's existing indexes can achieve, while maintaining acceptable recall.

Why pgvector's Indexes Become a Bottleneck

Limitations of IVFFlat

IVFFlat partitions vectors into buckets via clustering, and at query time only scans the few buckets closest to the query vector. This works reasonably well when the data is evenly distributed, but once the distribution is skewed or the number of clusters is set poorly, you run into a dilemma: too few buckets scanned causes recall to collapse, while too many buckets scanned causes speed to degrade.

Key parameters in IVFFlat: Using IVFFlat requires setting lists (the number of clustering buckets) and, at query time, probes (the number of buckets actually scanned). As a rule of thumb, lists is often set to rows / 1000 (when rows are under a million) or sqrt(rows), while probes must be tuned to balance recall against latency, typically starting from sqrt(lists). Recall is extremely sensitive to probes, because when the query vector lands on the edge of a cluster, the true nearest neighbors may be distributed across adjacent buckets—this is exactly the root cause of what the original text calls "too few buckets scanned leading to recall collapse."

Key parameters in HNSW: m controls the number of neighbors each node retains in the graph (default 16), ef_construction determines the candidate queue size during construction (default 64), and at query time ef_search controls the search breadth. Increasing m and ef_construction can improve recall, but significantly increases build time and memory usage, since the graph structure needs to store all nodes and their adjacency lists in memory.

The Cost of HNSW

HNSW uses a multi-layer graph structure, descending at query time from a sparse upper-level graph to a dense lower-level graph, and typically provides the best recall-latency curve. The cost is high memory usage, long build times, and significant maintenance overhead under frequently updated workloads. For write-intensive applications, HNSW is often not the ideal choice.

Pg_vectorsearch attempts to find a new balance point between the two.

The Core Idea Behind Pg_vectorsearch

From publicly available information, Pg_vectorsearch does not follow the classic IVF or HNSW route, but instead designs a new index structure with optimization focused on the following dimensions:

• Query latency: reducing the number of vectors that must be visited per query at the same recall level
• Index build speed: lowering the computational overhead during the build phase so that large datasets can be indexed faster
• Memory efficiency: controlling resident memory usage while maintaining performance

If these goals can be achieved simultaneously, it would deliver real value for scenarios that require both low-latency queries and frequent index rebuilds—such as real-time feature updates in recommendation systems.

Comparison with pgvector Indexes

According to benchmark data provided by the project team, Pg_vectorsearch surpasses pgvector's IVFFlat and HNSW in query throughput. Note that the results of such benchmarks are highly dependent on dataset characteristics, vector dimensionality, recall targets, and hardware configuration.

When making a real-world selection, it's worth paying attention to the following points:

1. Recall-latency curve: Don't just look at a single latency number—look at latency performance at your target recall level
2. Build time and resource consumption: For scenarios requiring frequent index rebuilds, build cost may be more critical than query cost
3. Update friendliness: The impact of insert, delete, and update operations on index performance
4. Ecosystem compatibility: Whether it's compatible with existing pgvector SQL interfaces, and how high the migration cost is

Core metrics for evaluating vector indexes:

• Recall@k: The proportion of the k results returned by a query that overlap with brute-force search (ground truth) results. It measures "how many true nearest neighbors were missed."
• P99 latency: 99% of queries complete within this latency. It better reflects the "slow queries" users actually experience than average latency, especially in recommendation, search, and other scenarios sensitive to long-tail latency.
• QPS (throughput): Queries per second, used to evaluate service capacity per unit of hardware resources.
• Index build time and memory: Determines whether the index can be rebuilt within an overnight window and how large a dataset a single machine can handle.

The fairness of a benchmark also depends on whether the recall target is fixed (e.g., comparing latency at Recall@10=0.95 for all candidates); otherwise, simply comparing QPS numbers can be misleading.

Impact on the Vector Database Landscape

The vector retrieval space currently shows clear divergence: dedicated vector databases (such as Milvus, Qdrant, Weaviate) push for extreme performance, while PostgreSQL+pgvector occupies a large number of small-to-medium-scale scenarios thanks to the convenience of "handling relational data and vector data in one database."

The emergence of projects like Pg_vectorsearch shows that competition within the PostgreSQL ecosystem is also intensifying. If the new index can deliver on its performance promises while remaining interface-compatible with pgvector, then for teams already using PostgreSQL, the upgrade path will be very smooth—no data migration, no query rewrites, just switching to a different index type.

Of course, new projects typically need time to prove themselves in terms of maturity, community support, and edge-case handling. Whether to adopt it depends on a team's tradeoff between stability and performance.

How dedicated vector databases and pgvector differ in positioning: Dedicated systems such as Milvus, Qdrant, and Weaviate are typically deeply optimized for distributed scaling, heterogeneous index types (such as DiskANN, ScaNN), and GPU acceleration, making them suitable for retrieval services at the billion-plus scale deployed independently. pgvector's advantage lies in transactional consistency for "relational data + vector data" in the same database—no need to sync data between a business database and a vector database, simplifying architecture and operations. The value of plugin-level solutions like Pg_vectorsearch lies precisely in keeping performance optimization inside Postgres, rather than requiring users to move vectors out for performance. This "index competition inside Postgres" is in fact narrowing the performance gap between dedicated databases and general-purpose databases.

Practical Recommendations

If you're using pgvector and running into performance bottlenecks, you can evaluate Pg_vectorsearch through the following steps:

1. Reproduce the benchmarks on your own dataset rather than trusting the project's numbers directly
2. Compare P99 latency at your target recall level (e.g., 95%), not average latency
3. Test index build time and required memory
4. Evaluate performance under real write workloads

For applications with vector scales under tens of millions and low latency sensitivity, pgvector's existing indexes may already be sufficient, and there's no need to introduce a new dependency. But for larger-scale, latency-critical scenarios, Pg_vectorsearch is worth watching.

One-line Summary

Pg_vectorsearch, a new vector index solution for PostgreSQL, aims to surpass pgvector's IVFFlat and HNSW in query speed.

Paragraph Summary

The article introduces the Pg_vectorsearch project discussed on Hacker News, a new index implementation targeting pgvector's performance bottlenecks. The author first analyzes the limitations of pgvector's two existing indexes: IVFFlat is sensitive to data distribution, and balancing cluster count versus scanned buckets to satisfy both recall and speed is difficult; HNSW, while offering an excellent recall-latency curve, has high memory usage, long build times, and costly update maintenance. Pg_vectorsearch claims to simultaneously optimize query latency, index build speed, and memory efficiency, with benchmark throughput surpassing pgvector. The article emphasizes that real-world selection requires validating the recall-latency curve, build cost, and update friendliness on one's own dataset, and notes that if it's compatible with the pgvector interface, migration cost for PostgreSQL users is extremely low, though project maturity still needs time to prove out.