As others have correctly pointed out, to make a vector search or recommendation application requires a lot more than similarity alone. We have seen the HNSW become commoditised and the real value lies elsewhere. Just because a database has vector functionality doesn’t mean it will actually service anything beyond “hello world” type semantic search applications. IMHO these have questionable value, much like the simple Q and A RAG applications that have proliferated. The elephant in the room with these systems is that if you are relying on machine learning models to produce the vectors you are going to need to invest heavily in the ML components of the system. Domain specific models are a must if you want to be a serious contender to an existing search system and all the usual considerations still apply regarding frequent retraining and monitoring of the models. Currently this is left as an exercise to the reader - and a very large one at that. We (https://github.com/marqo-ai/marqo, I am a co-founder) are investing heavily into making the ML production worthy and continuous learning from feedback of the models as part of the system. Lots of other things to think about in how you represent documents with multiple vectors, multimodality, late interactions, the interplay between embedding quality and HNSW graph quality (i.e. recall) and much more.
Choosing vector database: a side-by-side comparison
81–90 of 125 posts
Re: Choosing vector database: a side-by-side comparison
#82Strongly disagree with PGVector's DX being worse than Chroma. Installing, configuring, and working with Chroma was infuriating -- it's alpha software and has the bugs and rough edges to prove it. The tools to support and interface with postgres are battle-tested and so much nicer by comparison; getting Chroma working took over a week, ripping it out and replacing with PGVector took a couple hours. Also agree with thi…
Thanks for your input, I've only tried Chroma a little bit so far and had a pretty good experience. What they also have going for them is a big community on discord that can be helpful.
Re: Choosing vector database: a side-by-side comparison
#83Earlier quoted context omitted.
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.
Amazon was already working on getting rid of ElasticSearch with their Kendra NLP search. Are you sure ElasticSearch has rosy future?
Amazon forked ElasticSearch into OpenSearch. When deciding which platform to go with (we are an AWS customer) I decided to stick with the company whose future depends on their search product (Elastic), not the one that could lose interest and walk away and suffer almost no consequences (AWS). If OpenSearch is still around in 5 years, and keeping pace with ElasticSearch, then maybe I'd consider it the next time I'm making this choice.
Also there's a lot more to ElasticSearch than full-text search (aggregations, lifecycle management, Kibana). Doesn't seem like Kendra is going to be a replacement for our use case.
Re: Choosing vector database: a side-by-side comparison
#84Earlier quoted context omitted.
What do you like about it relative to alternatives? How fast is it?
+1 for Vespa. For me it is VERY resilient and production ready. It is such a dream compared to Elasticsearch, that we migrated from.
Does Vespa have an equivalent of Kibana? and how hard was the migration?
Re: Choosing vector database: a side-by-side comparison
#85Redis is definitely missing in the comparison.
Re: Choosing vector database: a side-by-side comparison
#86Earlier quoted context omitted.
Amazon was already working on getting rid of ElasticSearch with their Kendra NLP search. Are you sure ElasticSearch has rosy future?
They have beef with ES since they took the software, made a bunch of cash on it, then never contributed back. ES called them out and it started a feud. I'd go on ES over Amazon-built software any day. I worked on RDS and I've used RDS at several companies, it's a mess. Longer story: One day one of our table went missing on Aurora, we couldn't figure out why, it was in the schema, etc. Devops panicked and restarted th…
>then never contributed back
Amazon did contribute back.
Re: Choosing vector database: a side-by-side comparison
#87Latency from embedding models is still going to be the bottleneck for performance however fast the DB is going to be. Plus adding all the overhead of synthesising answers and summaries from a LLM is going to weigh you down.
Embeddings can be precomputed. Imagine a related videos section a video sharing site. Each video's embedding is relatively static.
Re: Choosing vector database: a side-by-side comparison
#88I really appreciate comparisons like this, although I find myself wanting to know more about why certain things are listed the way they are. For example, pgvector is listed as not having role-based access control, but the Postgres manual dedicates an entire chapter to it: https://www.postgresql.org/docs/current/user-manag.html Hence why I’d be interested to know more about the supporting details for the different cat…
Same for Developer experience. If you used Postgres or any other relational db (which I think covers a large % of devs), you could easily argue the dev experience is 3/3 for pgvector.
Not only 3/3 but also includes full text search built in. Tables look like:
MyThingEmbedding
______
id primary key
mything_id integer -- fkey to mything table
embedding vector(1536)
fulltext tsvector
GIN index on tsvector
HSNW index on embedding
Re: Choosing vector database: a side-by-side comparison
#89Earlier quoted context omitted.
If you're interested in an approach like this, take a look at txtai. 1. https://neuml.github.io/txtai/embeddings/indexing/ 2. https://neuml.hashnode.dev/external-database-integration
I love this idea. It seems like a very practical approach. I'm going to give this a try on my next project.
It's practical and simple. This approach just plugs the index id similarity matches into the RDBMS query.
Re: Choosing vector database: a side-by-side comparison
#90I'll add txtai to the list: https://github.com/neuml/txtai txtai is an all-in-one embeddings database for semantic search, LLM orchestration and language model workflows. Embeddings databases are a union of vector indexes (sparse and dense), graph networks and relational databases. This enables vector search with SQL, topic modeling and retrieval augmented generation. txtai adopts a local-first approach. A production…
I know David and have used txtai extensively. txtai is awesome and if you care at all about open source, you should give it a shot!