Loading today’s stories
Build1 distinct publisher3 min readUpdated
Nine query shapes, five graph databases, every one on its smallest tier. The self-hosted engines answered reads in 1-4ms; the managed free tiers sat flat between 35ms and 310ms.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A dev.to post has published a five-database graph benchmark run entirely on the smallest tier each vendor offers, with the code and raw results in a public GitHub repo [1][2][3]. It matters because the number that decides whether an MVP survives is what the cheap instance does under realistic queries, and in this run the product the post is named after did not win.
The setup is the interesting part. Nine queries were run identically against CognoDB Cloud, Memgraph, Neo4j Community, ArangoDB Oasis and FalkorDB Cloud: a point lookup, a 1-hop and a 2-hop traversal, a two-edge-type recommendation pattern, a bounded shortest path, a user-scoped and a global aggregation, and two writes [3][4]. The dataset was 7,000 people, 2,800 products and roughly 56,000 relationships [5], which works out to about 9,800 nodes and 5.7 relationships per node [19]. It was sized to fit FalkorDB's 100 MB free-tier cap, which the post says was the tightest constraint in the comparison, not CognoDB's [6]. Each query reports p50, p95 and p99 latency plus throughput, with load time and connection setup time kept as separate numbers [7].
The results split along hosting, not vendor. Memgraph and Neo4j Community, both capped at 0.5 vCPU and 256 MB in Docker but running on the same machine as the client, answered point lookups and 1-hop reads in 1-4ms [9]. CognoDB and ArangoDB Oasis sat at roughly 245-310ms and FalkorDB at about 35ms, flat from point lookup through two-hop traversal [10]. That is 60x to 310x the self-hosted read latency for the slower managed band [18], and the CognoDB/Oasis band is about 7 to 9 times FalkorDB's floor [17]. The author reads the flatness as network round-trip dominating the measurement rather than the query planner [11], and names FalkorDB's ~35ms as the best of the three managed options that completed reliably [15].
The disclosures are worth more than the latencies. The post is written from the CognoDB side, headlined "We benchmarked CognoDB against four graph databases" [1], and it says the 256 MB Docker cap was chosen to match an assignment brief's stated CognoDB spec while the real CognoDB dashboard reports 512 MB, meaning the self-hosted baseline was more starved than CognoDB itself [12]. That was disclosed rather than corrected, because correcting it means re-running everything [12]. Neo4j AuraDB Free, the most direct comparator, was dropped because its signup asked for billing details before provisioning, which broke the benchmark's own free-tier, no-credit-card rule; the code still supports it [8]. The stated method was that every database runs on its smallest tier, every spec is written down, and where a managed vendor does not publish exact vCPU and RAM, the post says so instead of guessing [13][14]. It bills itself as a template for not trusting benchmarks, including this one [20].
Two results, per the post, do not fit the network-latency explanation, and the first is that CognoDB's free instance did not hold up under sustained load [16]. The copy available here is truncated before the detail [16].
What to watch: whether the 256 MB versus 512 MB mismatch gets re-run on equal terms [12], whether anyone reproduces the managed numbers from a different region to test the round-trip claim [11], and how quickly a real dataset outgrows FalkorDB's 100 MB cap and takes the 35ms floor with it [6][10].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The dataset was one shared graph of 7,000 people, 2,800 products and approximately 56,000 relationships, described as big enough to have real hub nodes and skewed degree distributions.
For each query the benchmark reports p50/p95/p99 latency and throughput, plus load time and connection setup time as their own separate numbers.
Memgraph and Neo4j Community, both running under a 0.5 vCPU / 256 MB Docker cap but on the same machine as the client, answered point lookups and 1-hop reads in 1-4ms.
The post concludes that for a managed free tier, FalkorDB's approximately 35ms floor was the best of the three managed options that completed reliably.
The post says two results do not fit the "just network latency" story and flags them separately; the first is that CognoDB's free instance did not hold up under sustained load, and the source text available here is truncated mid-sentence before the detail.
A post on dev.to by Hassan Yosuf is headlined "We benchmarked CognoDB against four graph databases. Here's what 'free tier' actually buys you." and is described as a field guide for choosing a managed graph database on a budget.
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.
Documented single-run harness, open code, no external verification
The methodology is unusually explicit for a blog benchmark: fixed query set, one shared dataset sized to the tightest free-tier cap, tier specs written down, percentile and throughput reporting, load and connection setup broken out, and code plus raw results published. Confounds are disclosed by the author rather than hidden — self-hosted engines shared a machine with the client, and the 256 MB Docker cap understated CognoDB's actual 512 MB. Against that, everything rests on one publisher's single pass: no repeat runs or variance, no measured network baseline to support the central network-round-trip interpretation, one anomaly explicitly left unisolated, and no independent replication of the repo's results.
No adoption signal in the supplied source
The cluster contains one measurement artifact and no adoption facts. There are no repository stars, forks, downloads, deployments, customer counts, usage disclosures or third-party pickups reported for either the benchmark harness or any of the five databases evaluated. Inferring adoption from a benchmark publication would be a guess.
Claims sit at or slightly below what the harness shows
The framing is self-limiting rather than promotional: it opens by calling itself a template for distrusting benchmarks, discloses a spec mismatch that biases against the vendor in the headline, publishes the failures of the database it was ostensibly built around, and refuses to claim exact specs it cannot verify. The recommendation it does make is narrow and hedged ('best of the three managed options that completed reliably'), and it is further qualified by the load-time inversion. The one place where assertion runs ahead of measurement is the network-round-trip explanation for flat managed latency, which is stated as 'the tell' without a supporting RTT figure; that pulls the gap back toward zero rather than positive.
Disclosed CognoDB-linked brief, partly offset by open code and unflattering findings
The post discloses that its Docker memory cap was chosen to match 'the assignment brief's stated CognoDB spec', indicating the work originated in a CognoDB-framed exercise, and CognoDB is the vendor in the headline — a structural alignment worth flagging, though the nature of any relationship or compensation is never described in the supplied text. Countervailing signals are strong: the code and raw results are published, CognoDB is placed mid-pack on latency and singled out for connection failures under sustained load, and a methodology error that made the comparison harsher on CognoDB's rivals is disclosed rather than corrected. The score reflects real but partially neutralized incentive exposure, not a finding of promotional intent.
Single publisher, single run, unreplicated
Every claim in this cluster traces to one dev.to post; there is no second publisher, no vendor response, and no independent reproduction of the linked repository. Internal quality is good for the genre — specific figures, named workloads, error types, disclosed confounds — but the measurements are single-pass with no variance reported, one anomaly is explicitly unresolved, the central latency interpretation lacks a measured baseline, and the supplied body is truncated mid-sentence in the network-latency discussion. Adoption is entirely unmeasured.
product
Oakley takes majority control of GraphDB's maker, with an acquisition mandate attached1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 16, 2026