Two of Our Six Graph Databases Died Under the Exact Same Load. Here's Why That's a Good Thing.

Sunny Bhatkar — Fri, 21 Aug 2026 01:55:17 +0000

Take-home assignment: benchmark CognoDB against a handful of other graph databases, fairly. The fairness rule was blunt — every database gets the same tiny resource cap, 0.5 vCPU, 256MB RAM, no exceptions.

Easy to say. Two platforms didn't survive it.

Memgraph kept getting killed by the Linux OOM reaper mid-import. First guess was a missing index. Wrong, checked, fixed, still died. Second guess was storage mode. Memgraph's analytical mode skips the write-ahead log for faster imports, sounded promising. Turns out it also doesn't support the uniqueness constraint the benchmark required — you get one or the other, not both. Back to the normal mode, ran it clean, one more time, just to check.

Killed again. Two clean failures with the config right isn't bad luck. It's Memgraph's in-memory transactional engine having a real memory floor a 256MB box can't clear.

ArangoDB failed for a completely different reason. Buried in its docs: it doesn't actually detect a Docker container's memory limit unless you tell it explicitly. Left alone, it sizes its internal cache off the host machine's RAM, not the container's. Set the override, got further, still died.

At that point the honest options were: loosen the cap until everything fits (which defeats the whole point), or ship with fewer databases than required. Neither felt right, so a fifth platform got added mid-project — Kùzu, an embedded graph database that runs inside your own process instead of as a separate server. No idle daemon sitting there before you've loaded a row.

Peak memory using it: 1.94MB. Out of 256MB. While Memgraph and ArangoDB were dying at that same number trying to hold identical data.

The actual results ended up more interesting than "local wins." Kùzu's "indexed" lookup isn't indexed at all — it's a full scan, no traditional index support by design. It still beat AuraDB's genuinely indexed lookup by roughly 40x (4.7ms vs 196.7ms). That's not a smarter query engine, that's a direct measurement of how much of a cloud database's latency is just internet round-trip, not actual work.

FalkorDB and Kùzu didn't split cleanly either. FalkorDB wins every traversal query, loses badly on aggregation — slower than a real cloud database for that one. Different engines, different strengths, no single winner.

None of this made it into a clean five-green-checkmarks table, and that's kind of the point. If the first Memgraph attempt had just worked, none of this would've surfaced.

Full methodology, every failure, every number: repo link.

DEV Community: Sunny Bhatkar

Two of Our Six Graph Databases Died Under the Exact Same Load. Here's Why That's a Good Thing.