pg_vectorsearch vs pgvector: The 42-Hour Vector Index Just Became a 100-Minute One

Tiger Data, the company behind TimescaleDB, introduced an open-source PostgreSQL extension called pg_vectorsearch, which includes a new index access method called PRISM. PRISM aims to address the issues users face when building large embedding tables with pgvector HNSW indexes that often take hours or even days to complete.

On a 128 GiB machine, PRISM finished building an index for 100 million embeddings in just 1 hour 40 minutes, whereas pgvector HNSW took 42 hours to do the same task on a 512 GiB machine. This demonstrates a significant performance improvement for PRISM. However, it is essential to note that PRISM requires PostgreSQL 18 or later, which may pose a challenge for many production deployments still on versions 15 through 17.

PRISM works by partitioning vectors into k-means clusters and storing them as compressed RaBitQ codes, allowing for faster index build times and smaller index sizes. In the benchmark tests, PRISM used 25 GB to store the same 100 million vectors, compared to HNSW's 180 GB. This reduction in index size results in faster query performance, with PRISM delivering 95% recall at a median latency of 6 ms, while HNSW took 8 ms on a machine with four times the memory.

Despite these positive aspects, PRISM is still in the alpha stage of development and is not recommended for production use. Some limitations include the need for manual rebalancing when there is heavy churn, deletions not reusing space, and the lack of support for filtered searches. Additionally, indexes created with PRISM should be recreated between releases, as they are considered disposable.

Before switching to PRISM, it is crucial to conduct independent benchmarking tests on your specific workload and hardware to determine if it offers the best performance improvement for your use case.