I sent the thread to Erik (the main contributor) though, so if you have feedback or questions, good chance that he'll see it.

This isn’t the first vector index we’ve built and open-sourced for PostgreSQL. In 2024, Tiger Data released pgvectorscale, which used a graph-based indexing algorithm inspired by Microsoft’s DiskANN research. We deliberately chose a disk-optimized design so that indexes could scale beyond available RAM. Our initial benchmarks were promising, but as adoption grew and we tested against a wider variety of datasets, particularly low-dimensional ones, we encountered a troubling problem: portions of the graph could become unreachable, causing recall to degrade. We searched the literature for a principled solution but couldn’t find one, and the heuristics we tried worked on some datasets but not others.

That’s a frustrating failure mode for a search index. When queries are slow, you can measure the problem and tune accordingly. But when recall degrades, you might not even notice until users start questioning the quality of their search results. And telling them to experiment with yet another set of tuning parameters isn’t the experience we want to provide.

Meanwhile, partitioned-list approaches reminiscent of IVFFlat were getting a second life, as advances in compression and optimization addressed many of their old limitations. More importantly, they offered stronger guarantees than we could achieve by patching a graph-based index. We came to believe they were a better foundation, and decided to start over.

With the introduction of pg_vectorsearch, we are shifting the majority of our vector-search development efforts to this new architecture. The existing pgvectorscale extension, which is stable and handling production workloads currently, will enter maintenance mode.