Any reason you didn’t contribute to pgvector?
It would have been nice to get the support of neon in progressing pgvector - since it’s already so widely adopted by the community
(disclosure: supabase ceo)
It would have been nice to get the support of neon in progressing pgvector - since it’s already so widely adopted by the community
(disclosure: supabase ceo)
Andrew is working hard on pgvector, and his goals are aligned to ours (and the industry's). We'll continue to support him as long as that's true.
> one of the slowest
Benchmarks are simply a snapshot in time - there's nothing fundamentally flawed with pgvector, it just needs more support and some better indexes (which are already being worked on)
[0] https://supabase.com/docs/guides/getting-started/architectur...
> Benchmarks are simply a snapshot in time - [...] it just needs [...] some better indexes
But the choice for IVF-flat indexes was made by the authors of pgvector, and that is one of the reasons why pgvector is slow: O(√n) optimal performance is just not great with large datasets, and this is especially true for the linked list approach chosen by the authors, as it results in large amounts of random IO.
You can't only implement a slow index and then shove the blame of the extension being slow on the index that was chosen by the extension authors: it is an inherent design issue. Sure, those can be fixed, but that doesn't mean it doesn't exist.
it would definitely be a design issue if the extension could only support a single index type, but Andrew already has plans to implement HNSW in 0.5.0:
If you say "no, pgvector is not slow, it is the index that is slow", while pgvector has been designed with only a single index type, then it is a design issue of pgvector in that the wrong type of index was chosen as the included index type.
That there are plans to solve this issue doesn't mean it is not an issue; indeed it validates my point that pgvector currently has design flaws.
Telling (potential) users to wait for 6 months for performance doesn't mean much if there are more performant alternatives readily available right now; a starving person isn't helped by a meal made available half a world away.
Scary that database engineers do not understand how reckless that is.
0.5.0 according to the GitHub issue tracker has been more than a year in the making and it is not any closer to release.
Our on disk path will require us to run a number of experiments with the storage format. We will move faster with a separate project.
Medium to long term we are very open to merge them.
> will require us to run a number of experiments with the storage format
I'd personally consider this a feature, if you want to maintain Postgres compatibility and allow your users to migrate in/out easily