Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case Against PGVector

alex-jacobs.com

Post reply on HN
Print view View original

11–20 of 144 posts

Re: The Case Against PGVector

#11

Post by VoVAllen »

VoVAllen wrote: post #9

We at https://github.com/tensorchord/VectorChord solved most of the pgvector issues mentioned in this blog: - We're IVF + quantization, can support 15x more updates per second comparing to pgvector's HNSW. Insert or delete an element in a posting list is a super light operation comparing to modify a graph (HNSW) - Our main branch can now index 100M 768-dim vector in 20min with 16vcpu and 32G memory. This enables user…

And we do have user hosting 3 Billion vectors with Postgres + VectorChord with sharding. And they're using vectors to save the earth! Check https://blog.vectorchord.ai/3-billion-vectors-in-postgresql-...

Re: The Case Against PGVector

#12

Post by rudderdev »

As others have commented, all the mentioned issues are resolved, I will favour in using the PGVector. If Postgres can be a good choice over Kafka to deliver 100k events/sec [1], then why not PGVector over Chroma or other specialized vector search (unless there is a specific requirement that can't be solved wit minor code/config changes)!

[1] Ref: https://news.ycombinator.com/item?id=44659678

Re: The Case Against PGVector

#13

Post by Fripplebubby »

clickety_clack wrote: post #7

My default is basically YAGNI. You should use as few services as possible, and only add something new when there’s issues. If everything is possible in Postgres, great! If not, at least I’ll know exactly what I need from the New Thing.

The post is a clear example of when YAGNI backfires, because you think YAGNI but then, you actually do need it. I had this experience, the author had this experience, you might as well - the things you think you AGN are actually pretty basic expectations and not luxuries: being able to write vectors real-time without having to run other processes out of band to keep the recall from degrading over time, being able to write a query that uses normal SQL filter predicates and similarity in one go for retrieval. These things matter and you won't notice that they actually don't work at scale until later on!

Re: The Case Against PGVector

#14

Post by sgarland »

> The problem is that index builds are memory-intensive operations, and Postgres doesn’t have a great way to throttle them.

maintenance_work_mem begs to differ.

> You rebuild the index periodically to fix this, but during the rebuild (which can take hours for large datasets), what do you do with new inserts? Queue them? Write to a separate unindexed table and merge later?

You use REINDEX CONCURRENTLY.

> But updating an HNSW graph isn’t free—you’re traversing the graph to find the right place to insert the new node and updating connections.

How do you think a B+tree gets updated?

This entire post reads like the author didn’t read Postgres’ docs, and is now upset at the poor DX/UX.

Re: The Case Against PGVector

#15

Post by alanwli »

I've seen a decent amount of production use of pgvector HNSW from our customers on GCP, but as the author noted is not without some flaws and are typically in the smallish range (0-10M vectors) for the systems characteristics that he pointed out - i.e. build times, memory use. The tradeoffs to consider are whether you want to ETL data into yet another system and deal with operational overhead, eventual consistency, application-logic to join vector search with the rest of your operational data. Whether the tradeoffs are worth it really depends on your business requirements.

And if one needs the transactional/consistency semantics, hybrid/filtered-search, low latencies, etc - consider a SOTA Postgres system like AlloyDB with AlloyDB ScaNN which has better scaling/performance (1B+ vectors), enhanced query optimization (adaptive pre-/post-/in-filtering), and improved index operations.

Full disclosure: I founded ScaNN in GCP databases and currently lead AlloyDB Semantic Search. And all these opinions are my own.

Re: The Case Against PGVector

#16

Post by nostrebored »

VoVAllen wrote: post #9

We at https://github.com/tensorchord/VectorChord solved most of the pgvector issues mentioned in this blog: - We're IVF + quantization, can support 15x more updates per second comparing to pgvector's HNSW. Insert or delete an element in a posting list is a super light operation comparing to modify a graph (HNSW) - Our main branch can now index 100M 768-dim vector in 20min with 16vcpu and 32G memory. This enables user…

So you’re quantizing and using IVF — what are your recall numbers with actual use cases?

Re: The Case Against PGVector

#17

Post by epolanski »

Curious if the author tried the new Redis module that brings HNSW vector search to redis.

From what I've seen is fast, has excellent API, and is implemented by a brilliant engineer in the space (Antirez).

But not using these things beyond local tests, I can never really hold opinions over those using these systems in production.

Re: The Case Against PGVector

#18

Post by xfalcox »

xfalcox wrote: post #3

> Nobody’s actually run this in production We do at Discourse, in thousands of databases, and it's leveraged in most of the billions of page views we serve. > Pre- vs. Post-Filtering (or: why you need to become a query planner expert) This was fixed in version 0.8.0 via Iterative Scans ( https://github.com/pgvector/pgvector?tab=readme-ov-file#iter... ) > Just use a real vector database If you are running a single ser…

Also worth mentioning that we use quantization extensively:

- halfvec (16bit float) for storage - bit (binary vectors) for indexes

Which makes the storage cost and on-going performance good enough that we could enable this in all our hosting.

Re: The Case Against PGVector

#20

Post by tacoooooooo »

VoVAllen wrote: post #9

We at https://github.com/tensorchord/VectorChord solved most of the pgvector issues mentioned in this blog: - We're IVF + quantization, can support 15x more updates per second comparing to pgvector's HNSW. Insert or delete an element in a posting list is a super light operation comparing to modify a graph (HNSW) - Our main branch can now index 100M 768-dim vector in 20min with 16vcpu and 32G memory. This enables user…

We actually looked into vectorchord--it looks really cool, but it's not supported by RDS so it is an additional service for us to add anyways.
Post reply on HN