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

Vector database built for scalable similarity search

milvus.io

Post reply on HN
Print view View original

51–60 of 95 posts

Re: Vector database built for scalable similarity search

#51

Post by bayan1234 »

dandiep wrote: post #25

I really don't want another database. I just want to have a solution built in for Postgres, and more specifically, RDS, which we use. I know there will be some extra difficulty that I will have to manage (e.g. reindexing to a new model that is outputting different embeddings), but I really don't want another piece of infrastructure. If anyone from AWS/Google/Azure is listening, please add pgvector [1] into your manag…

Yes exactly. My company has asked AWS if they will be adding support for pgvector for rds but they haven't been able to confirm if that will happen any time soon.

If the vectors are in the same database as the tabular/structured data then text to sql applications of llm's are so much more powerful. The generative models will then be able to form complex queries to find similarity as well as perform aggregation, filtering and joining across datasets. To do this today with a separate dedicated vector db is quite painful.

Re: Vector database built for scalable similarity search

#53

Post by andre-z »

jamesblonde wrote: post #45
mikeortman wrote: post #34

Earlier quoted context omitted.

Pinecone is closed-source AND hosted-infra only... which is a non-starter for many companies.

Pinecone offers a free managed tier, which was quite nice until it lost my data last month. They did eventually recover it a few days later, to be fair to them.

Qdrant also offers a 1GB free tier https://cloud.qdrant.io

Re: Vector database built for scalable similarity search

#54

Post by ttt3ts »

jhgg wrote: post #20
fzliu wrote: post #8

Earlier quoted context omitted.

Not yet, but this functionality should be coming soon. We're currently working on adding the capability to call third party embedding APIs directly from a Zilliz Cloud instance.

I was mulling over the idea of building keyword image search (say, with CLIP based embeddings). However I'm not really sure the cost, or whether or not this is the best solution. Do you have any case studies about large deployments of this software, and what the upper limits of scale might be?

Don't start with mullivus if you're learning. Too much yak shaving. Try https://github.com/criteo/autofaiss.

Also, TBH, it is a lot cheaper to run a simple faiss index.

Re: Vector database built for scalable similarity search

#55

Post by ttt3ts »

tommoor wrote: post #28

It feels like there are an influx of "vector databases" right now, I haven't had a strong answer out of anyone on why you'd be better off using these over Redis which offers vector storage with similarity search in a battle-tested OSS solution.

Redis uses too much memory and supports only two NN algorithms FLAT (very slow) and HNSW if you start indexing millions of large vectors you will quickly understand the problem.

That being said, many of these DBs are overcomplicated for most use cases. Redis HNSW will work for many use cases.

Re: Vector database built for scalable similarity search

#57

Post by fzliu »

ttt3ts wrote: post #55
tommoor wrote: post #28

It feels like there are an influx of "vector databases" right now, I haven't had a strong answer out of anyone on why you'd be better off using these over Redis which offers vector storage with similarity search in a battle-tested OSS solution.

Redis uses too much memory and supports only two NN algorithms FLAT (very slow) and HNSW if you start indexing millions of large vectors you will quickly understand the problem. That being said, many of these DBs are overcomplicated for most use cases. Redis HNSW will work for many use cases.

Redis does fairly well single-threaded - iirc it does better than Milvus. The problem is, once you move to larger applications and want higher performance, its architectural limitations make it impossible to scale.

Re: Vector database built for scalable similarity search

#59

Post by jamesblonde »

orasis wrote: post #6

Can these databases do fast averaging of nearest neighbors for regression or do you have to retrieve the neighbors and manually compute a mean across them?

They are primarily for storing wmbeddings for similarity search - not general purpose nearest neighbor algorithms.

Re: Vector database built for scalable similarity search

#60

Post by hobofan »

tommoor wrote: post #28

It feels like there are an influx of "vector databases" right now, I haven't had a strong answer out of anyone on why you'd be better off using these over Redis which offers vector storage with similarity search in a battle-tested OSS solution.

One positive thing I can say about Weaviate is that it's incredibly simple to get started with it, as it handles talking to the vectorizer(s) for you, and they provide many out of the box container images for them. With that we were able to integrate a similarity search into our product very quickly.

From what I can tell, its competitors generally don't do this, and you have to handle generating the embeddings and all the back and forth with the embeddings yourself, setting the barrier for integration much higher.

If you are at a level where you want to get a lot more control about embeddings, I agree that there it will often be better to just use the vector search capabilities that your existing solution like Redis/Postgres are getting.

Post reply on HN