Exactly. We talk to teams every week who spent a month setting up pinecone or qdrant and then realize they just needed search that worked. The vector database became the default answer to every search problem because of the RAG hype cycle, even when the actual need is way simpler

Can you describe when the actual need is much simpler? I mean throwing documents into elastic search is really easy and the search is really good.

one use case we're handling right now is for a large online auction marketplace. they needed to automatically categorize 40,000 newly uploaded images per week. no tags, no metadata from the sellers, just raw photos. elasticsearch can't look at an image and tell you it's a vintage rolex or a mid-century lamp. they needed search that understands visual content, not text

that's the kind of problem where keyword search doesn't apply at all, no matter how good the engine is

> Spent a month setting up Pinecone? Really?

there's a lot more in "setting up" than creating an account and a collection on pinecone or any other service

That RAG is marketing and doesn't significantly affect performance is incorrect. As to whether retrieval really benefits from vector DBs is another question.

True. RAG is worse in almost all real-world use cases. If you have less than 10,000 documents its worse and if you have too many documents its also worse.

this is way too broad, RAG works fine in the 10k-1M doc range if your chunking and retrieval pipeline are tuned properly. the failure mode is usually bad embeddings or naive chunking, not RAG itself.