> we've seen many companies and organizations hop on the vector search bandwagon, from NoSQL database providers such as MongoDB (via Atlas Vector Search) to traditional relational databases such as Postgres (via pgvector). The general messaging I hear around these vector search plugins is largely the same and goes something like this: developers should stick with us since you can store tables/JSON in addition to vectors, so there is no need to manage multiple pieces of infrastructure!
> This kind of statement always cracks me up, as it's clearly crafted by unsophisticated marketing teams
From the conclusion:
> Once your application starts requiring more complex workloads (such as joins or aggregations), that's when you'll want to contemplate using different data stores.
I don’t know, after reading through the post I’ve come away on the side of the “unsophisticated marketing teams”; if the vector DB doesn’t have transactions, joins, aggregations it sounds like I’d hit its limitations pretty quick and then I’d rather have an all-in-one industrial strength DB like Postgres instead of two systems.
You joke, but you would not blame redis for not doing joins. Vector databases are really more like caches that do similarity search. Maybe we should call them vector stores.
> Give me all the people who are attracted to people like this one
This can be handled with a simple batch query rather than a join, even if you want to query for multiple users, fetching all of their related users. In qdrant, for example: https://qdrant.tech/blog/batch-vector-search-with-qdrant/
This is what gets me more and more with LLMs and their "ability to code". A join is a bedrock of a database. Always has been. Always will be. All LLMs are an absolute shitshow when it comes to any SQL logic involving joins. It's hilariously bad. But what can I expect from an LLM when apparently even people consider a JOIN a "more complex workload"? What a joke.
Obviously it is a more complex workload. Consider a simple database like a hash map. Accessing one record in that map is easy, but it should be quite apparent that you need quite a bit more logic if you want to join that record with other records.
And that's not far off how current generation vector stores are implemented. They are not designed for efficient joins (nor aggregations) and changing that, like above, does require a more complex workload.
There is no free lunch in engineering, just a choice in which trade-offs you are willing to pay for.
Eh? SQL is one area where I’ve found LLMs – at least, ChatGPT – to be surprisingly decent. I’ve even had it translate relational algebra back and forth.
PgVector stores the index in memory right? Do you really want your primary db using all its memory for vectors and all its cpu for doing vector dot products?
There are significant differences in performance, accuracy, and other aspects when using a general-purpose database like PostgreSQL. These differences can lead to bottlenecks in performance and data scale. You can refer to this comparison article to learn more
https://myscale.com/blog/myscale-vs-postgres-opensearch/
show me what I can't do in pgvector that I can do in your vector database. That's all I need to see. If you're only answer is, "it doesn't scale", I'll need you to be specific about "scale".
On top of my head, pgvector only supports 2 indexes, those are running in memory only. They don't support GPU indexing, nor Disk based indexing, they also don't have separation of query and insertions.
Also with different people I've talked to, they struggle with scale past 100K-1M vector.
> we've seen many companies and organizations hop on the vector search bandwagon, from NoSQL database providers such as MongoDB (via Atlas Vector Search) to traditional relational databases such as Postgres (via pgvector). The general messaging I hear around these vector search plugins is largely the same and goes something like this: developers should stick with us since you can store tables/JSON in addition to vectors, so there is no need to manage multiple pieces of infrastructure!
> This kind of statement always cracks me up, as it's clearly crafted by unsophisticated marketing teams
From the conclusion:
> Once your application starts requiring more complex workloads (such as joins or aggregations), that's when you'll want to contemplate using different data stores.
I don’t know, after reading through the post I’ve come away on the side of the “unsophisticated marketing teams”; if the vector DB doesn’t have transactions, joins, aggregations it sounds like I’d hit its limitations pretty quick and then I’d rather have an all-in-one industrial strength DB like Postgres instead of two systems.
reply