A CognoDB-side benchmark puts the vendor mid-pack, and ships the repo so you can check

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].