A field guide to the two storage paradigms behind every serious LLM application — scored on retrieval, reasoning, cost, and the questions each one can and cannot answer.
A marketplace client in Mumbai came to me with a genuinely good question. Their LLM support agent kept giving almost right answers about their catalog — thousands of products, suppliers, and delivery zones — because the knowledge lived in a vector database that could find "similar" things but could not answer questions like "which suppliers ship to Zone 4 and have a return rate under 3%?" That question requires combining two conditions and traversing a relationship. A vector search cannot do it. A knowledge graph can — and only if it has been built with those relationships in the first place.
That client conversation is the entire argument of this article, so let me be direct about the framing: vector databases and knowledge graphs are not interchangeable, they answer different questions, and most teams pick one because it is fashionable rather than because it fits their queries. I have now shipped both in production for clients — Qdrant and pgvector on the vector side, Neo4j on the graph side — and I am going to score them on the criteria that actually decide budgets, not the ones that decide conference talks.
