Loading today’s stories
Build1 distinct publisher3 min readPublished
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
Compiled by The EngineerSomething wrong?How this is made
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 [2] [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 [12]. 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%" [2]. The other breaks on a 10kg parcel matching the chunk for a different weight band [14]. Both are numeric comparisons, not topical misses [1], 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 [10] [14]. So corpus type does not predict fit [3]. 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 [5]. 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 [3], 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 [4]. 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 [11]. The fashion problem he names [4] 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 [5] [2], and the 1 to 5 comparison table he says decides budgets is referred to but not reproduced in the text we have [9]. 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 [1] [8]. Those are the ones no amount of embedding quality will reach.
Ranked by verification strength, evidence, and original report placement.
The author says he has shipped both in production for clients: Qdrant and pgvector on the vector side, Neo4j on the graph side.
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.
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.
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.
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.
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.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Mechanism plausible, outcomes single-sourced
The descriptive core — embeddings with top-k nearest retrieval, chunk-as-unit-of-knowledge, graph nodes and edges traversed deterministically in Cypher or SPARQL, schema and entity-extraction labour — is conventional and internally consistent, and the derived reading that both failures broke on a numeric comparison follows directly from the text. But every outcome and quantitative claim rests on one practitioner's account of two unnamed client engagements in a single dev.to post, the 1-5 scored table the argument leans on is absent from the supplied text, and the tens-of-milliseconds retrieval figure carries no methodology or definition of scale. No contradicting or corroborating source exists in the cluster.
Three disclosed unnamed client deployments
Adoption signal exists but is thin and entirely self-reported: two client systems running in production over vector stores (a marketplace support agent, a logistics rate card) plus the author's disclosure of shipping Qdrant, pgvector and Neo4j for clients. No client is named, no user counts, corpus sizes, spend, or timelines are given, and there is no independent usage disclosure, release, or benchmark from any vendor or third party in the cluster.
Superlatives outrun the two cases behind them
Mildly overstated. The framing is authoritative — a 'field guide to the two storage paradigms behind every serious LLM application', vectors 'unbeatable', vectors 'useless' where precision is needed, a graph 'the only honest answer' — and it is anchored to a 1-5 production scoring table that is not present in the supplied text, all on the strength of two unnamed engagements. Against that, the article is candid about graph labour, cost and awkwardness at semantic search, and its central mechanism claim is uncontroversial, so the gap is a matter of register rather than of fabricated substance. Its own sharpest insight is arguably understated: the article sells a corpus-type binary while its evidence shows the real discriminator is whether the answer requires a comparison the index cannot compute.
Consultant credibility marketing, no disclosed vendor tie
The author writes as a consultant who advises paying clients on exactly this choice and foregrounds having shipped both stacks in production, so the piece functions in part as expertise signalling, and the anonymity of the two client cases means the central evidence cannot be checked by readers. Offsetting this, the supplied text discloses no vendor sponsorship or commercial relationship with any named product, treats competing tools even-handedly (multiple vector stores listed, Qdrant explicitly exonerated for the rate-card failure), and volunteers the weaknesses of both paradigms including the graph labour cost. Nothing in the cluster evidences a pay-for-placement or vendor-alignment incentive, so this is scored as moderate rather than high.
Confident on mechanism, weak on outcomes
Confidence is moderate and asymmetric. The mechanical and definitional claims, and the derived observation that both failures hinge on numeric comparison, can be read directly off the text and are consistent with well-known retrieval behaviour, so they are safe to rely on. Everything measurable — latency, cost, the 1-5 scores, the frequency of these failure modes — is single-sourced, anonymised and unverifiable, and the cluster contains no second publisher to triangulate against, which caps the overall assessment below the halfway mark.
build
DuckDB's vss extension removes a database from your RAG stack, then names the price1 distinct publisher
build
Four control planes, one Postgres: a team's case against polyglot persistence1 distinct publisher
build
A Gulf bank's compliance rule priced out to $133 of GPU per seat1 distinct publisher
build
Your RAG Cannot Find SKU-4471, And A Bigger Embedding Model Will Not Help1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026