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

131–140 of 144 posts

Re: The Case Against PGVector

#131

Post by inbx0 »

I don't have much experience in dedicated vector databases, I've only used pgvector, so pardon me if there's an obvious answer to this, but how do people do similarity search combined with other filters and pagination with separate vector DB? It's a pretty common use case at least in my circles.

For example, give me product listings that match the search term (by vector search), and are made by company X (copanies being a separate table). Sort by vector similarity of the search term and give me top 100?.

We have even largely moved away from ElasticSearch to Postgres where we can, because it's just so much easier to implement with new complex filters without needing to add those other tables' data to the index of e.g. "products" every time.

Edit: Ah I guess this is touched a bit in the article with "Pre- vs. Post-Filtering" - I guess you just do the same as with ElasticSearch, predict what you'll want to filter with, add all of that to metadata and keep it up to date.

Re: The Case Against PGVector

#132

Post by neya »

smallerfish wrote: post #127
neya wrote: post #126

Man, that table comparison definitely looks like it was AI generated. I'm starting to question the whole article itself, now :/

The copy reeks of being AI written, which is ironic given: > It’s a compelling story. And like most of the AI influencer bullshit that fills my timeline, it glosses over the inconvenient details.

Haha, nice catch

Re: The Case Against PGVector

#133

Post by Xx_crazy420_xX »

The author (human or llm) flips between performance ("millions of vectors") and semantic accuracy ("only 3 match your filter") to push its point, depending on what needs to look worse. AI framing switch that was that was probably introduced by RLHF on humans that don't think critically but want somewhat convincing answers.

For pre-filtering "You’re still searching millions of vectors" isn't valid argument, because the author does not relate to any alternative, and post-filtering is even worse.

Re: The Case Against PGVector

#134

Post by tacoooooooo »

Xx_crazy420_xX wrote: post #133

The author (human or llm) flips between performance ("millions of vectors") and semantic accuracy ("only 3 match your filter") to push its point, depending on what needs to look worse. AI framing switch that was that was probably introduced by RLHF on humans that don't think critically but want somewhat convincing answers. For pre-filtering "You’re still searching millions of vectors" isn't valid argument, because th…

Author is a human :). Performance and semantic accuracy are both important. The point about pre-filtering _youre still searching millions of vectors_ is important because once you apply a filter you can no longer use your vector index. And doing a full scan on millions of vectors is quite expensive

Re: The Case Against PGVector

#137

Post by redwood »

MongoDB's implementation separates the vector index runtime from the transactional processing enabling independent scaling and workload isolation but preserving unified query richness and scale-out via sharding. This is a best of both worlds in my view...

Re: The Case Against PGVector

#138

Post by Xx_crazy420_xX »

tacoooooooo wrote: post #134
Xx_crazy420_xX wrote: post #133

The author (human or llm) flips between performance ("millions of vectors") and semantic accuracy ("only 3 match your filter") to push its point, depending on what needs to look worse. AI framing switch that was that was probably introduced by RLHF on humans that don't think critically but want somewhat convincing answers. For pre-filtering "You’re still searching millions of vectors" isn't valid argument, because th…

Author is a human :). Performance and semantic accuracy are both important. The point about pre-filtering _youre still searching millions of vectors_ is important because once you apply a filter you can no longer use your vector index. And doing a full scan on millions of vectors is quite expensive

Maybe i was just too narrow focused on the comparison itself and did not get that point. Anyways, as a whole was a valuable read, along with hn comments made me reconsider current implementations details in my projects

Re: The Case Against PGVector

#139

Post by tacoooooooo »

codingjaguar wrote: post #108

This quite aligns with our observation at Milvus. Recently, we helped several users migrate from pgvector as the workload grew substantially. It’s worth recognising the strengths of pgvector: • For small-to-medium scale workloads (e.g., up to millions of vectors, relatively static data), embedding storage and similarity queries inside Postgres can be a simple, familiar architecture. • If you already use Postgres and…

well said! we demo'd milvus (or zilliz i should say,) and while we didn't ultimately go with it--it seems like a great option

Re: The Case Against PGVector

#140

Post by mannyv »

"It works, until it doesn't."

The question is, at what point does it not work?

Vacuuming is grief enough. Rebuilding the index sounds like more of a nightmare than with Solr/Lucene. And what happens when indexing fails? In Solr/Lucene it used to mean you were dead. I'm sure they fixed that, but at some level you need to either be behind on one while you reindex or figure out some queueing system that works like transactions.

Post reply on HN