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

51–60 of 144 posts

Re: The Case Against PGVector

#51

Post by xfalcox »

dpflan wrote: post #33
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…

What are you using it for? Is it part of a hybrid search system (keyword + vector)?

In Discourse embeddings power:

- Related Topics, a list of topics to read next, which uses embeddings of the current topic as the key to search for similar ones

- Suggesting tags and categories when composing a new topic

- Augmented search

- RAG for uploaded files

Re: The Case Against PGVector

#52

Post by throwway120385 »

Fripplebubby wrote: post #13
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…

Many of the concerns in the article could be addressed by standing up a separate PG database that's used exclusively for vector ops and then not using it for your relational data. Then your vector use cases get served from your vector DB and your relational use cases get served from your relational DB. Separating concerns like that doesn't solve the underlying concern but it limits the blast radius so you can operate in a degraded state instead of falling over completely.

Re: The Case Against PGVector

#53

Post by riku_iki »

chandureddyvari wrote: post #46

Is there a comprehensive leaderboard like ClickBench but for vector DBs? Something that measures both the qualitative (precision/recall) and quantitative aspects (query perf at 95th/99th percentile, QPS at load, compression ratios, etc.)? ANN-Benchmark exists but it’s algorithm-focused rather than full-stack database testing, so it doesn’t capture real-world ops like concurrent writes, filtering, or resource manageme…

> Is there a comprehensive leaderboard like ClickBench

clickbench has 100m rows of data only, which makes it not comprehensive benchmark at all.

Re: The Case Against PGVector

#54

Post by riku_iki »

alanwli wrote: post #15

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, a…

AlloyDb is not opensource, so it is kinda different niche.

Re: The Case Against PGVector

#55

Post by antirez »

epolanski wrote: post #17

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.

It's not a module, it is part of every new Redis version now. Well, actually: it is written in the form of a module and with the modules API in order to improve modularity of the Redis internals, but it is a "merged module", a new implementation/concept I implemented in Redis exactly to support the Vector Sets use case. Thank you for mentioning this.

Re: The Case Against PGVector

#56

Post by riku_iki »

softwaredoug wrote: post #47

My real icky feeling is the layering on of postgres plugins to get a search solution to work. Ok yeah there's PGVector. Then you need something to do full text search. And if you put all that together, you have a complex Postgres deployment. It seems to make sense for simple operations, but I'd rather just get a search engine / vector database, than try to twist Postgres's arm into a weird setup.

> do full text search. And if you put all that together, you have a complex Postgres deployment.

search is also just extension? So, its a strong point: you have one self-contained server with simple installation/maintenance story.

Re: The Case Against PGVector

#57

Post by antirez »

Redis Vector Sets, my work for the last year, I believe address many of such points:

1. Updates: I wrote my own implementation of the HNSW with many changes compared to the paper. The result is that the data structure can be updated while it receives queries, like the other Redis data types. You add vectors with VADD, query for similarity with VSIM, delete with VREM. Also deleting vectors will not perform just a thumbstone deletion. The memory is actually reclaimed immediately.

2. Speed: The implementation is fast, fully threaded reads, partially threaded writes: even for insertion it is easy to stay in the few hundreds of ops/sec, and querying with VSIM is like 50k ops/sec in normal hardware.

3. Trivial: You can reimplement your use case in 10 minutes including learing how it works.

Of course it costs some memory, but less than you may guess: it supports quantization by default, transparently, and for a few millions of elements (most use cases) the memory usage is very low, totally affordable.

Bonus point: if you use vector sets you can ask my help for free. At this stage I support people using vector sets directly.

I'll link here the documentation I wrote myself as it is a bit hard to find, you know... a README inside the repository , in 2025, so odd: https://github.com/redis/redis/blob/unstable/modules/vector-...

P.S. in the README there is stale mention about replication code being not really tested. I filled the gap later and added tests, fixed bugs and so forth.

Re: The Case Against PGVector

#58

Post by epolanski »

mkesper wrote: post #21
epolanski wrote: post #17

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.

It's fast...because everything needs to be in memory. Expect astronomical cloud costs even for mid-sized data requirements.

I don't know what mid-sized data requirement is or how this is used in prod, but I have huge doubts that if performance is the need cost is the problem.

Especially in the AI and startup space.

Re: The Case Against PGVector

#59

Post by akulkarni »

tacoooooooo wrote: post #27
arunmu wrote: post #19

There is pgvectorscale from timescale which uses disk ann based data structure and has support for pre and post filtering.

I mention this towards the end of the post. it looks like a good solution, but it's not available on RDS

pgvectorscale is 100% open source

please ask your RDS rep to support it

we (tiger data) are also happy to help push that along if we can help

Re: The Case Against PGVector

#60

Post by bob1029 »

I'm still stuck on whether or not vector search (regardless of vendor) is actually the right way to solve the kinds of problems that everyone seems to believe it's great at.

BM25 with query rewriting & expansion can do a lot of heavy lifting if you invest any time at all in configuring things to match your problem space. The article touches on FTS engines and hybrid approaches, but I would start there. Figure out where lexical techniques actually break down and then reach for the "semantic" technology. I'd argue that an LLM in front of a traditional lexical search engine (i.e., tool use) would generally be more powerful than a sloppy semantic vector space or a fine tuning job. It would also be significantly easier to trace and shape retrieval behavior.

Lucene is often all you need. They've recently added vector search capabilities if you think you really need some kind of hybrid abomination.

Post reply on HN