Live data from Hacker News

Choosing vector database: a side-by-side comparison

benchmark.vectorview.ai

71–80 of 125 posts

Re: Choosing vector database: a side-by-side comparison

#71

What advantage are vector databases providing above using an index in conjunction with a mature database? I’m not sold on this as a separate technology. Vector search is useful, but I don’t understand why I would go out of my way when I could implement FAISS or HNSWlib as an adjunct to postgres or a document store.

The thing is if you need a vector _database_ there is no reason why it can't be a pg extensions. And if you project is only small scale there is probably some HNSW pg extension library you could use.

But what is most times needed instead of a vector database is a efficient fast responsive vectore approximate KNN search system with fast attribute filtering which overlaps with a fast an efficient text search system (e.g. bm25 based)

And if you then go to billion vector scale things become tricky performance wise.

And then you reach the same point at which companies do things like using warehouse approach where you have a read only extremely read optimized mostly in memory variant of their db they access for searches only and changes from their main db a streamed to the read only search instance, potentially while losing snapshot views, transactions and similar.

You could say that approx. KNN vector search is the new must have feature for unstructured fuzzy text search, and while you can have unstructured fuzzy text search in pg it's also often not the go-to solution if your databse is just for getting that search.

Re: Choosing vector database: a side-by-side comparison

#74
post #44

Everyone I talk to who is building some vector db based thing sooner or later realizes they also care about the features of a full-text search engine. They care about filtering, they care to some degree about direct lexical matches, they care about paging, getting groups / facet counts, etc. Vectors, IMO, are just one feature that a regular search engine should have. IMO currently Vespa does the best job of this, tho…

My company is using vector search with Elasticsearch. It’s working well so far. IMO Elastic will eat most vector-first/only products because of its strength at full-text search, plus all the other stuff it does.

I tend to agree - search, and particularly search-for-humans, is really a team sport - meaning, very rarely do you have a single search algo operating in isolation. You have multiple passes, you filter results through business logic.

Having said that, I think pgvector has a chance for less scale-intense needs - embedding as a column in your existing DB and a join away from your other models is where you want search.

I don’t get why you’d want to bolt RBAC onto these new vector dbs, unless it’s because they’ve caused this problem in the first place…

Re: Choosing vector database: a side-by-side comparison

#75

Their definition about Hybrid Search is I think wrong. Through this terms tend to not be consistently defined at all, so "wrong" is maybe the wrong word. Their definition seem to be about filtering results during (approximate) KNN vector search. But that is filtering, not hybrid search. Through it might sometimes be implemented as a form of hybrid search, but that's an internal implementation detail and you probably…

The way you explain hybrid search aligns with my understanding. Pinecone has a good article about it here https://www.pinecone.io/learn/hybrid-search-intro/. From my understanding, all vector DBs support this.

Re: Choosing vector database: a side-by-side comparison

#76
post #72

16x difference between pg and milvus? I thought for most use cases this would be quite performance sensitive

Yeah, that's the difference we've seen according to the QPS for the ANN Benchmarks. The same story seems to be true for other datasets too. We're looking at a 0.9 recall.

Re: Choosing vector database: a side-by-side comparison

#77

You might want to add https://turbopuffer.com/ as well now in the benchmarks.

Turbopuffer looks like something I would consider. And the pricing looks to be lowest on the list from what I can see

Emil if you email me at info@turbopuffer.com I can let you into the alpha :)

Re: Choosing vector database: a side-by-side comparison

#78

I've been wondering about Redis as vector database [0]. [0]: https://twitter.com/sh_reya/status/1661136833848438784

I quickly took a look at the redisearch ANN Benchmarks and they seem to stack up against the others (more or less same level as Milvus) in the comparison when it comes to QPS and Latency.

Re: Choosing vector database: a side-by-side comparison

#79

None of these vector dbs seem economical outside of enterprise.

Many of them are open source and you can host them yourself. That would make it more cost effective. Also someone mentioned https://turbopuffer.com/. That seems like a good alternative if you're looking for something economical.

Re: Choosing vector database: a side-by-side comparison

#80
post #12

I don't think we need specialized databases for vectors. Relational databases can easily be expanded by vector data types and operations. They will eventually catch up by supporting what was once a unique feature of the new system: https://medium.com/@magda7817/two-things-to-keep-in-mind-bef...

Yeah, maybe they will.. But for now, the best options are the purpose-built vector databases, so why not use them?
Post reply on HN