4 ms·

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

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)

nikita 3y ago
I think IVFFlat and HNSW are very different implementations. So we would be forcing a choice for a pgvector user of what index to use. 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.
- kiwicopple 3y ago
  They are different, but that doesn't preclude pgvector supporting both indexes. I get that it's slower to take a collaborative approach - but that's part of open source. > 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
nikita 3y ago
https://github.com/pgvector/pgvector/pull/86 https://github.com/pgvector/pgvector/pull/86 an example of why it's better to have our own project to move fast.
KRAKRISMOTT 3y ago
A more important question is why supabase went with one of the slowest [0] implementations instead of building a better plugin especially since you are a VC funded company that's hardly lacking in cash. Simply gluing together a few random open source extensions is not great for developer experience. [0] https://github.com/erikbern/ann-benchmarks https://github.com/erikbern/ann-benchmarks
- kiwicopple 3y ago
  that's a fair question. it's our policy to support existing open source tools/companies as much as we can[0] 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/architecture#support-existing-tools https://supabase.com/docs/guides/getting-started/architectur...
  - sam_goody 3y ago
    [flagged]
  - mattashii 3y ago
    >> [...] why supabase went with one of the slowest implementations > 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.
    - kiwicopple 3y ago
      > it is an inherent design issue 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: https://github.com/pgvector/pgvector/issues/27 https://github.com/pgvector/pgvector/issues/27
      - KRAKRISMOTT 3y ago

nikita 3y ago

I think IVFFlat and HNSW are very different implementations. So we would be forcing a choice for a pgvector user of what index to use. 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.

kiwicopple 3y ago
They are different, but that doesn't preclude pgvector supporting both indexes. I get that it's slower to take a collaborative approach - but that's part of open source. > 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

nikita 3y ago

https://github.com/pgvector/pgvector/pull/86 https://github.com/pgvector/pgvector/pull/86 an example of why it's better to have our own project to move fast.

KRAKRISMOTT 3y ago

A more important question is why supabase went with one of the slowest [0] implementations instead of building a better plugin especially since you are a VC funded company that's hardly lacking in cash. Simply gluing together a few random open source extensions is not great for developer experience. [0] https://github.com/erikbern/ann-benchmarks https://github.com/erikbern/ann-benchmarks

kiwicopple 3y ago
that's a fair question. it's our policy to support existing open source tools/companies as much as we can[0] 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/architecture#support-existing-tools https://supabase.com/docs/guides/getting-started/architectur...
- sam_goody 3y ago
  [flagged]
- mattashii 3y ago
  >> [...] why supabase went with one of the slowest implementations > 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.
  - kiwicopple 3y ago
    > it is an inherent design issue 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: https://github.com/pgvector/pgvector/issues/27 https://github.com/pgvector/pgvector/issues/27
    - KRAKRISMOTT 3y ago