For example: (taken from a project I'm currently working on)
```
SELECT *
FROM report_embeddings a
INNER JOIN report_embeddings b
ON (
subvector(a.embedding, 1, 768)::vector(768) <-> ) < $1
AND b.id != a.id
AND a.embedding <-> b.embedding < $1
In this example, I truncate the embedding to 768 dimensions for the index and the lookup, (see the INNER JOIN) but do an additional full vector comparison as well. (in the WHERE clause)
This performs a fast but less accurate lookup into the index, and then only does the non-indexed full vector check for the matched results.
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.
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.
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.