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

31–40 of 95 posts

Re: Vector database built for scalable similarity search

#31

Post by fzliu »

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…

Totally with you on that - it's annoying to need multiple pieces of infrastructure, especially for solo developers or small teams. Often times, you want to filter further based on scalar fields/metadata such as timestamps, strings, numeric values, etc...

That's why we built attribute filtering into Milvus via a Mongo-esque interface. No SQL and not as performant as an RDBMS, but it's an option: https://milvus.io/docs/hybridsearch.md

Re: Vector database built for scalable similarity search

#33

Post by thomasahle »

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.

Vector search is still a semi active area of research. You can't get "battle tested" and optimal performance at the same time.

Re: Vector database built for scalable similarity search

#35

Post by qwick23 »

tbh. Looks like a huge overengineered legacy project. What is the clue to having all these ANN indexes in place? Is it a kinda art collection? What is the sense when you can just have HNSW in memory, with quantization, or on disk, GPU accelerated, etc. There are already better alternatives like Qdrant, which is written in Rust and super performant https://github.com/qdrant/qdrant, or Weaviate with GraphQL interface https://github.com/weaviate/weaviate

Re: Vector database built for scalable similarity search

#36

Post by qwick23 »

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…

With Postgres, you can do almost everything, also a full-text search, but you still have Elasticsearch, Mejlisearch, etc when you need performance and advanced features. The multitool approach is suboptimal in most cases.

Re: Vector database built for scalable similarity search

#37

Post by killthebuddha »

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.

I'm currently evaluating different vector stores and passed on Redis today after spending about a half day looking into it. Here's my reasoning

    1. The Node.js client is designed to be just a thin wrapper around Redis commands. The client's docs basically just point you straight at the Redis docs.

    2. The `@redis/search` API is slightly different than the FS.SEARCH Redis command's api. The difference is not documented and cost me ~20 minutes. This is a pretty big problem given item 1.

    3. The `@redis/search` TypeScript types didn't allow some valid FS.SEARCH calls.
One thing to note is that for some use cases (IMO probably a large fraction of use cases right now), the vectors are derived data, so you don't necessarily need a super robust/battle-tested "database", you just need something with a simple happy-path API.

Re: Vector database built for scalable similarity search

#38

Post by killthebuddha »

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…

FWIW supabase recently added support:

https://supabase.com/docs/guides/database/extensions/pgvecto...

Re: Vector database built for scalable similarity search

#39

Post by qwick23 »

killthebuddha wrote: post #37
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.

I'm currently evaluating different vector stores and passed on Redis today after spending about a half day looking into it. Here's my reasoning 1. The Node.js client is designed to be just a thin wrapper around Redis commands. The client's docs basically just point you straight at the Redis docs. 2. The `@redis/search` API is slightly different than the FS.SEARCH Redis command's api. The difference is not documented…

What do you think about Weaviate or Qdrant? There is a nice benchmarks overview with all the major players https://qdrant.tech/benchmarks/

Re: Vector database built for scalable similarity search

#40

Post by adobrawy »

qwick23 wrote: post #36
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…

With Postgres, you can do almost everything, also a full-text search, but you still have Elasticsearch, Mejlisearch, etc when you need performance and advanced features. The multitool approach is suboptimal in most cases.

In small teams, the infrastructure is often not able to be fully utilized, so performance is not an issue. However, feature richness allows this team to deliver higher-level feature faster. Think early stage startup (one or two engineers) or hairdressers-like business (they use a ready-made framework that targets a popular database and limits its feature to have a wide range of users). As a result, you can have a lot of such business creating a very long tail.
Post reply on HN