alt Hacker NewsI have used pgvector on an Azure DB. It did a "reasonable" job. I am not an expert on HNSW vs PRISM but because it is all backward compatible, I am curious why they didn't just send a PR to the pgvector folks?
Like, I would love to learn more about the design process that led to a whole new thing. I am sure the decision was not taken lightly, but the README is very thin on the details for why anyone should go through the troubles above, at least in the making of it.
Replies
Main pg_vectorsearch contributor here. There are multiple reasons why simply “sending a PR” is more difficult than it sounds.
As a company, we want to move at a different pace and try things that a project like pgvector wouldn’t necessarily allow (and rightfully so). pg_vectorsearch is alpha-level software, while pgvector is stable. Releasing early is a way to make it available to the community sooner and getting feedback.
Then there are all kinds of technical reasons: different architectures, different implementation choices, etc. There's also the freedom to try new things and going in completely different directions.
"Just sending a PR" is not that easy
[flagged]
Fair question. When we built our first vector extension, pgvectorscale, we actually reached out to pgvector's author to see if they'd be interested in supporting additional index types (at the time, DiskANN-based), so we could contribute our work directly to pgvector. At the time, their preference seemed to be to focus on the existing index types rather than expand the project in that direction. We respected that decision and went ahead with a separate extension.
But one of the great things about open source and PostgreSQL's extension architecture is that these projects can coexist! pg_vectorsearch can work directly with pgvector's existing data types, so developers can use either index.