A five-way graph database benchmark spent its first four hours measuring undersea cable

An engineer asked to compare CognoDB Cloud against Neo4j AuraDB, Memgraph, FalkorDB and ArangoDB on the same data and workloads produced a clean-looking first table in which FalkorDB was about 2,700 times faster on a single indexed lookup, 0.09 ms against 239.61 ms ^[1][2]. The gap is reproducible and, by the author's own account, close to worthless: CognoDB's free instance had provisioned into Google Cloud's us-east4 region in Northern Virginia, and the author is in Telangana, India ^[2][3].

The query took roughly a millisecond to execute; the round trip to Virginia took about 243 ^[4]. FalkorDB was not winning an engine contest, it was running in a container under the desk ^[5]. On the author's own figures, comparing engine time to engine time puts the two roughly 11x apart rather than 2,700x, which is a different article entirely ^[19].

The geography could not be tuned away. Neo4j AuraDB landed in Singapore, about 88 ms out, so the two managed instances were not even on the same continent as each other, and neither free tier offers a region selector ^[6][7]. The author verified Aura's location rather than assuming it, resolving its hostname to an IP inside Google's published Singapore range, and noted that the roughly 15,000 km Singapore-to-Virginia gap matches the 156 ms difference measured ^[8][9]. The two ping figures subtract to 155 ms, which is the same story from the other end ^[20].

The fix was to stop trusting the wall clock. Bolt drivers expose the server's own execution time with the network excluded, so every latency is reported three ways: raw wall clock, which is what a user in India actually feels, RTT adjusted, and server reported ^[10][11]. In pure engine time, according to the author, the platforms sit far closer together than the raw table implies ^[12].

The second finding is the one operators should copy into their loaders. The import into CognoDB completed and reported 23,211 relationships per second; the verification read afterwards found zero relationships ^[13]. Every isolated test passed. Batches of 10, 100, 1,000 and up to 10,000 edges each created exactly what was asked ^[14]. Writes immediately after building indexes, immediately after dropping them, and in two different Cypher phrasings were all fine ^[15]. The clue was version-shaped: CognoDB runs v0.9.11 and does not recognise db.awaitIndexes(), the standard call for waiting until indexes are ready, which redirected suspicion from the queries to index timing ^[16]. CognoDB builds indexes in the background, and on this dataset that took 28.8 seconds ^[17]. The section concerns 150,000 relationships that never existed ^[18]. At the reported 23,211 per second, that entire import would have finished in about 6.5 seconds, roughly a fifth of the index build window ^[21]. A success code was returned for data that was not retained.

Worth watching: whether managed free tiers keep shipping instances into whatever region they please while being used for public latency tables ^[7], and whether ingestion tooling treats a driver's success response as proof of persistence. The write-up breaks off mid-sentence while noting there is also no clean way to ask CognoDB whether the background index build has finished, so the remediation is not fully documented in the text as supplied ^[22].