BuildNot yet confirmed elsewhere1 publisher3 min readPublished
The query a vector index cannot answer, whatever you embed it with
A consultant's two client failures, a supplier filter and a 10kg shipping quote, both broke on a numeric comparison that top-k similarity does not perform.
The Engineer · Build desk
What happened
- A consultant reports a Mumbai marketplace whose LLM support agent kept returning almost right catalog answers because its knowledge sat in a vector database.
- The question that broke it: which suppliers ship to Zone 4 and have a return rate under 3 percent, two conditions plus a relationship traversal.
- A second client stored its whole rate card as vector chunks; a 10kg Mumbai to Delhi quote came back from the chunk for a different weight band, confidently.
- The same practitioner says he has run Qdrant, pgvector and Neo4j in production, and argues teams choose by fashion rather than by query shape.
- He still rates vectors unbeatable for document retrieval, measuring top-5 chunk lookup at tens of milliseconds at meaningful scale.
Why it matters
- constraint No encoder upgrade buys a threshold filter, so money spent on embedding quality cannot reach this class of question; the ceiling is in the index, not the model.
- cost The failure arrives as a confident answer rather than an error, so it is paid by whoever acts on the output while the retrieval stack logs a successful query.
- decision Going to a graph commits a team to declaring relationships before anyone asks the question, making it a modelling job with an ingest bill rather than a query engine swap.
- exposure Anything with priced tiers behind an LLM answer is reachable the same way: the customer is quoted a number nobody checked against the band boundaries.
Top-k retrieval does one thing: embed the question, rank stored chunks by distance, return the source text of the winners [6]. The Zone 4 question asks for something else, namely a set intersection over two attributes, one of them a numeric threshold, joined across a relationship that has to exist somewhere as an edge [3] [7]. No ranking function produces that. The author's blunt version is the accurate one: the store cannot do WHERE clauses, because each chunk is an island and there is no supplier object anywhere holding a return rate [10]. A better encoder changes which island you land on. It does not create the join.
Put the two reported failures side by side and they rhyme more tightly than the article claims. One breaks on "under 3%" [3]. The other breaks on a 10kg parcel matching the chunk for a different weight band [12]. Both are numeric comparisons, not topical misses [14], and in both cases the retrieved text was plausibly on-subject, which is exactly why it passed.
That is where the article's own framing strains. The rate card case is retrieval-augmented generation over documents, the workload the author calls unbeatable for vectors and clocks in tens of milliseconds at meaningful scale [18] [12]. So corpus type does not predict fit [15]. A rate card arrives as bands before anyone chunks it; the chunking is the step that discards the band boundaries the question needs, and after that the index has the same island problem as the supplier attributes [17]. The useful discriminator is not documents versus entities. It is whether answering requires a comparison the index cannot compute.
The graph side is not free either, and the source says so in passing: a knowledge graph answers the supplier query only if it was built with those relationships in the first place [4], with entities and edges declared and traversed in Cypher or SPARQL [7]. That moves the work from query time to schema time rather than removing it [16]. Against that sits the cheapness the author credits to vectors: pgvector inside the PostgreSQL you already run, Qdrant standing up in a weekend, one vector per chunk instead of a web of edges [9]. The fashion problem he names [5] is partly a budgeting problem, because the store that is cheap to install is also the one that quietly cannot answer a whole class of question.
Worth holding the evidence at its actual weight. This is two client engagements described by one practitioner who has shipped both sides [1] [13], and the 1 to 5 comparison table he says decides budgets is referred to but not reproduced in the text we have [19]. The mechanism argument stands on its own; the scores would need to be seen. What the two cases do establish is a cheap design check: list the questions the system must answer, and mark the ones containing a threshold, a band, or an "and" across two attributes [14] [8]. Those are the ones no amount of embedding quality will reach.
What to watch
- Publication of the 1 to 5 scored table the author says decides budgets, which would let the cost and reasoning claims be checked rather than taken on trust.
- Any measurement showing the two-condition supplier query answered without a graph, which would move the boundary from architectural to solvable.
- Whether the logistics client's rate card ends up in a graph or simply back in a table, a route the article's two-store framing does not cover.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence32
- Adoption24
- Hype gap+14
- Incentives42
- Confidence46
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The author says he has shipped both in production for clients: Qdrant and pgvector on the vector side, Neo4j on the graph side.
- [2]
A consultant describes a Mumbai marketplace client whose LLM support agent kept giving almost right answers about a catalog of thousands of products, suppliers and delivery zones, because the knowledge lived in a vector database.
- [3]
The question the vector store could not answer was "which suppliers ship to Zone 4 and have a return rate under 3%?", which the author says requires combining two conditions and traversing a relationship.
- [4]
The author states a vector search cannot answer that query, and that a knowledge graph can only if it has been built with those relationships in the first place.
- [5]
The author argues vector databases and knowledge graphs are not interchangeable and that most teams pick one because it is fashionable rather than because it fits their queries.
- [6]
Vector databases store embeddings as high-dimensional vectors; querying means embedding the question, finding the top-k nearest vectors and returning their source text, with a chunk of text as the unit of knowledge.
- [7]
Knowledge graphs store entities and relationships as first-class citizens, with nodes such as Supplier, Zone and Product and edges such as SUPPLIES_TO and HAS_RETURN_RATE, queried by traversal in Cypher or SPARQL, exactly and deterministically.
- [8]
The author's summary to clients is that a vector database answers "what is similar?" and a knowledge graph answers "what is related, and how?", and that most real applications have some of both.
- [9]
The author says setup is easy because pgvector runs inside PostgreSQL a team already has and a dedicated store such as Qdrant is a weekend to stand up, and cost at scale is friendly because you store one vector per chunk rather than a web of edges.
- [10]
The author states vectors cannot do WHERE clauses and cannot combine "ships to Zone 4" with "return rate under 3%" because each chunk is an island, with no notion of a supplier having a return rate or a zone being reachable.
- [11]
The author says top-k retrieval will happily return a chunk that looks relevant and is factually wrong for the exact question, and the LLM will answer from it, producing fluent-sounding wrong answers that he calls the most expensive kind.
- [12]
A logistics client stored its entire rate card as vector chunks; the question "What does shipping cost from Mumbai to Delhi for a 10kg parcel?" retrieved the closest chunk, which described a different weight band, and the answer was confidently wrong. The author calls this a category error rather than a bug in Qdrant.
- [13]
The article's evidence base is two client engagements reported by a single practitioner who has worked on both sides of the comparison, with no third-party measurement supplied.
- [14]
Both failures reported in the article turn on a numeric comparison, a return rate below 3% and a 10kg weight band, rather than on topical mismatch between question and chunk.
- [15]
The rate card failure occurred in document retrieval, the workload the author calls unbeatable for vectors, so corpus type does not predict fit; the discriminator is whether the answer requires a comparison the index cannot compute.
- [16]
Because a graph answers the relational query only when the relationships were modelled at ingest, the effort moves from query time to schema time rather than disappearing.
- [17]
A rate card's weight bands are structure that chunking leaves unrepresented, which places the shipping quote failure in the same island category as the missing supplier attributes.
- [18]
For retrieval-augmented generation over documents the author calls vectors unbeatable, and says he has measured retrieval of the top-5 most relevant chunks of an embedded policy manual at tens of milliseconds at meaningful scale.
- [19]
The article refers to a comparison table scored 1 to 5 from production experience, covering retrieval, reasoning, cost and the questions each store can answer, but the table's rows and scores do not appear in the supplied text.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toVector Database vs Knowledge Graph: Choosing Your LLM Store
1 article · August 25, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- LLM Data ArchitectureFollow
- Knowledge GraphsFollow
- Vector Databases and Search EnginesFollow
- Retrieval-Augmented GenerationFollow
- RAG Failure ModesFollow