Loading today’s stories
Build1 distinct publisher3 min readPublished
An independent rebuild of the SQLite side says the gap is real, but the published tables measure two different queries on two different graphs, so the depth at which SQLite's plan collapses on your data is a number you have to take yourself.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two of the published series point in opposite directions. On 100K nodes and 500K edges with the adjacency cache warm, the multiple falls as hops accumulate: 36x at one hop, 14x at two, 6x at three [4][5][6]. In the depth-limited series it climbs: 390x at depth 10, 713x at 15, 1,848x at 25, and 2,819x at depth 50 [8]. Those are two different queries on two different graphs, not one property called graph traversal.
Watch the absolute times and the falling multiple stops looking like bad news. At one hop the saving is 282 microseconds per query [1]. At three hops it is about 1.0 millisecond [2]. The ratio dropped six-fold while the wall clock on the table grew about three and a half times [3]. Ratios divide out the thing you are actually buying.
Now the arithmetic that decides the purchase. One millisecond a query means roughly a thousand three-hop traversals to reclaim a single second of latency [4]. One depth-50 traversal reclaims 1.4 seconds on its own [9], worth about 1,400 of the three-hop ones [5]. Divide the rounded absolutes at depth 50 and you get 2,800x [7], so the headline number is arithmetically honest. It is also a statement about a query almost nobody runs on a hot path.
The crossover is not in the published data. The fixed-hop table stops at three hops on 100K nodes; the depth-limited table starts at depth 10 on a 10K-node graph [6]. Between those two points the graph shrinks by an order of magnitude and the query form changes. The depth at which SQLite's plan stops keeping up on your graph is therefore a measurement you take yourself.
My hypothesis, offered as one: a recursive CTE re-materializes a work table each iteration, so its cost tracks rows accumulated, while an adjacency walk over a resident graph tracks edges expanded. The benchmark graph has a power-law degree distribution [11], where the frontier saturates the reachable component early. Past that depth SQLite keeps paying and LatticeDB has little new to visit. If that is the mechanism, the crossover is a function of your degree distribution and your working set, not of the engine. The project publishes the command to reproduce its harness [11], which is where I would test it before believing any of the above.
Credit where it is earned. The SQLite comparison is the only one in the docs run in the same harness on the same machine [11], and the docs tell you to read the depth series as how much depth costs rather than as a blanket speed multiple [10]. The Neo4j and Kuzu rows are labelled as third-party figures on hardware the authors do not control [12]. The vector table is labelled cross-benchmark: 0.83 milliseconds for 10-nearest-neighbour over 1M vectors at 100 percent recall@10, against server databases that also pay network overhead and against sqlite-vec's 17-millisecond brute force [13]. Docs that tell you which of their own numbers not to trust are rarer than fast traversals.
Adoption cost is short to state. MIT license, Zig, Python, TypeScript and Go bindings, about 300 GitHub stars when the author checked [15]. The Cypher subset covers MATCH, variable-length paths, MERGE, WITH, UNWIND and aggregations, without OPTIONAL MATCH or CALL procedures [14]. The author has read the source and the harness and has not shipped on it [16], which is the correct amount of confidence for a project at that star count.
Ranked by verification strength, evidence, and original report placement.
A dev.to writeup by jamilxt rebuilt the SQLite side of LatticeDB's benchmark on the author's own server and hardware, while quoting the LatticeDB figures from the project's published benchmark and its head-to-head comparison doc.
LatticeDB is an embedded, single-file property-graph database written in Zig, launched as a Show HN and positioned as "like SQLite but for graph databases", with native HNSW vector search and BM25 full-text search in the same query layer.
The marketing number circulating for LatticeDB is up to 2,819x faster graph traversal than SQLite.
LatticeDB's own docs tell readers to read the depth series as "how much does depth cost you", not as "LatticeDB is 3,000 times faster".
The LatticeDB-versus-SQLite comparison is the only one in the project's docs measured in the same harness on the same machine, over a social-network graph with a power-law degree distribution, and the project publishes the command to reproduce it.
In LatticeDB's README the Neo4j and Kuzu numbers are third-party figures measured on hardware the authors do not control.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 30, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
The query a vector index cannot answer, whatever you embed it with1 distinct publisher
build
Agent memory products differ on one thing: whether anything decides a fact is dead1 distinct publisher
build
DuckDB's vss extension removes a database from your RAG stack, then names the price1 distinct publisher
build
Your RAG Cannot Find SKU-4471, And A Bigger Embedding Model Will Not Help1 distinct publisher
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.
One side checked, one side quoted
Every ratio in this story is half verifiable. jamilxt rebuilt the SQLite denominator on his own hardware and tells you the graph shape, the index layout and the query form; the LatticeDB numerator comes entirely from the vendor's benchmark doc. The internal arithmetic holds up — the rounded depth-50 absolutes really do divide to about 2,800x against a published 2,819x — and the project marks its own borrowed and cross-benchmark rows, which is rarer than it should be. Nobody has measured LatticeDB.
Stars, not deployments
Three hundred stars, three bindings, a permissive licence and a launch post. The writer who read the source most carefully volunteers that he has shipped nothing on it, and no other user appears anywhere in this reporting. Everything on the table is interest; none of it is production.
The travelling number is the wrong number
2,819x is what circulates; 6x is what three hops on a 100K-node graph returned. The gap is not the project's doing — its docs say to read the depth series as the price of depth, not as a blanket multiple — so the overstatement lives in the figure that travels, not in the paperwork behind it. Pulling the other way: from the graph's most connected node SQLite took 705.9 milliseconds at three hops and 3.79 seconds at depth 1-to-5, far worse than the quoted baseline, so on hub-heavy data the modest published multiples understate the pain.
The winning half is self-measured
The numerator of every comparison was produced by the party it flatters, on a harness that party wrote, in launch week. Two things cut against the obvious discount: the project labels its third-party Neo4j and Kuzu rows and its cross-benchmark vector rows as such, and it ships the command to reproduce the one head-to-head test. jamilxt declares no stake and no shipped use; his incentive is the ordinary one a dev.to post carries, and he spends it on rerunning the half he could.
Direction yes, magnitudes no
A single publisher, with the vendor's documentation standing behind every LatticeDB figure — thin footing for any specific ratio. What lifts it off the floor is disclosure: the method, the hardware, the root-node choice that changed everything, and the caveats are all on the page, and the arithmetic survives a check. Trust that depth is where SQLite's plan gives way; do not trust any one multiple to hold on your data.