Pg_vectorsearch: An Index That Is Faster Than Pgvector’s IVFFlat And HNSW

TL;DR

Before you orderOffer from Amazon

Get the latest gadgets delivered free with Prime

• Fast, free delivery on millions of items
• Prime Video, Amazon Music and more included
• Member-only deals all year

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

Timescale’s pg_vectorsearch project has introduced PRISM, an approximate nearest-neighbor index for PostgreSQL that the project says outperforms pgvector’s IVFFlat and HNSW in its benchmarks. The extension is in alpha and is intended for testing, not production; the available source material does not provide detailed benchmark results to independently assess the performance claims.

Timescale’s pg_vectorsearch project has introduced PRISM, a PostgreSQL index for approximate nearest-neighbor search that its developers say is faster to query and build than pgvector’s IVFFlat and HNSW. The extension is marked alpha and not for production use, and the source material presents performance comparisons as project claims rather than independently verified results.

PRISM, short for Partitioned Routing Index for Similarity Matching, is a PostgreSQL-native index access method implemented in C. Its design is described as similar in broad outline to IVFFlat, but it combines a hierarchical centroid tree, quantized vector representations and partitioned posting lists to narrow the set of vectors considered during a search.

The project says PRISM is faster than IVFFlat and HNSW for both queries and index building. It also reports that, on a dataset of 100 million vectors, PRISM searches faster than HNSW at equivalent recall while using an instance with one-quarter of the memory. The supplied project summary does not include the benchmark tables, hardware details or test settings needed to evaluate those comparisons independently.

For search, PRISM traverses the centroid tree to select clusters, scans their posting lists, and uses RaBitQ quantization with error bounds to filter candidates before reranking them against full-precision vectors. The project says its distance calculations are optimized for SIMD instruction sets including AVX2, AVX-512 and NEON. It also supports inserts, updates and deletes, with posting-list maintenance available through a rebalance operation.

A New Option for PostgreSQL Vector Search

If the reported results hold across workloads, PRISM could give PostgreSQL operators another way to scale vector similarity search without moving data to a separate search system. Faster index construction can reduce the time needed to make large collections searchable, while lower memory use could matter for teams running high-dimensional workloads on constrained infrastructure.

Compatibility may lower the cost of testing it. The project says users can install the extension alongside pgvector and create a PRISM index directly on existing vector or halfvec columns, leaving tables and queries unchanged. That may allow a side-by-side evaluation before an operator removes an existing HNSW index. However, alpha status means reported speed and compatibility should not be treated as a production guarantee.

The likely benefit is workload-dependent. Approximate search trades exactness for speed, and PRISM exposes a setting, prism.nprobe, that affects how many clusters are searched. The project describes the default as automatic and associated with roughly 0.95 recall, but users would need to test their own data, query patterns and recall targets before drawing conclusions.

How PRISM Fits With pgvector

PostgreSQL users commonly use pgvector to store embeddings and run similarity searches. Its IVFFlat index groups vectors into lists, while HNSW uses a graph-based structure to find nearby vectors. PRISM takes a different route: it organizes clusters in a hierarchy and uses quantization to reduce the number of full-precision comparisons.

The project offers its own vec32 and vec16 data types for new tables, and says those types are binary-compatible with pgvector’s vector and halfvec types. For existing pgvector tables, it says a PRISM index can be built on the current column without rewriting or copying the stored vectors. The project lists L2 distance, inner product and cosine distance operators, and directs users to its documentation for build instructions and tuning details.

That compatibility does not change the release caveat: the repository labels the extension alpha, advises against production use, and warns that upgrading between prereleases may not be possible. It tells testers to plan to drop and recreate the extension and its indexes when upgrading, and to review the changelog for known issues.

““Status: alpha. Meant for testing, not production.””

— The pg_vectorsearch project documentation

Benchmark Scope and Alpha Risks

The supplied source does not specify the benchmark hardware, dataset composition, vector dimensions, query workload or exact recall settings behind its comparisons. It also does not provide independent test results. The claims that PRISM is faster than both IVFFlat and HNSW therefore remain claims made by the project, not a settled finding across PostgreSQL deployments.

It is also unclear from the supplied material how performance varies across different data distributions, update rates and concurrency levels, or what operational trade-offs arise from maintaining the index. The project flags known issues in its changelog but the source excerpt does not enumerate them. Since this is an alpha release, stability, upgrade paths and production readiness remain open concerns.

Testing Before Production Use

The project directs users to its repository for build instructions, architecture notes, tuning guidance and the changelog. Teams interested in the index can test it against their own data and compare query speed, index-building time, memory use and recall with their current pgvector setup. The documentation recommends checking query plans when both PRISM and an existing index are present.

No production release date or formal benchmark publication is stated in the supplied source. For now, the next developments to watch are changes in the project’s alpha status, updates to known issues, and more fully documented comparisons across datasets and hardware. Users should treat prerelease upgrades as potentially requiring a drop and rebuild of the extension and indexes.

Key Questions

What is pg_vectorsearch?

pg_vectorsearch is a PostgreSQL extension for approximate nearest-neighbor search. Its central feature is PRISM, an index intended to find similar vectors while reducing the amount of full-precision work needed for each query.

Is PRISM proven to be faster than IVFFlat and HNSW?

The project says PRISM is faster for querying and index building, and reports a comparison with HNSW on a 100-million-vector dataset. The supplied material does not include detailed benchmark methods or independent results, so the claims should be tested against the workload in question.

Can PRISM index an existing pgvector column?

According to the project, yes. It can be installed alongside pgvector and used to build an index on existing vector or halfvec columns without rewriting or copying the column.

Is pg_vectorsearch ready for production?

No. The repository labels it alpha and says it is intended for testing, not production. It also warns that prerelease upgrades may require dropping and recreating the extension and its indexes.

What does the prism.nprobe setting do?

prism.nprobe controls the number of clusters examined during a search, affecting the speed-recall trade-off. The project says its automatic default is associated with about 0.95 recall; users should check the tuning guide and validate recall on their own data.

Source: hn