> 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.