I Gave Five Graph Databases 256MB of RAM Each. Here's What Broke.

CognoDB Cloud's free tier gives you a graph database instance with half a CPU core and 256MB of RAM. That's not a lot. It's also, honestly, a pretty realistic starting point a lot of real side projects and early-stage products live exactly there, on whatever the free tier happens to give them, and find out the hard way what their database does under pressure.

So I decided to actually find out. I took CognoDB and lined it up against four other graph databases Neo4j AuraDB, FalkorDB, and ArangoDB gave every single one of them the same tiny resource budget, threw the same 198,050-edge dataset at all of them, and ran the same queries. No cherry-picking, no "best case" numbers. Just: here's a small VM's worth of resources, go.

One of the databases I originally planned to include never even made it into the results. It crashed on startup. Not "slow to start" a full segfault, reproducibly, across two different versions, with nothing I threw at it fixing it. More on that below, because it's honestly one of the more interesting parts of this whole thing.

The setup, quickly

Five candidates going in: CognoDB (mandatory, since that's the actual point of this), Neo4j AuraDB Free, Memgraph, FalkorDB, and ArangoDB. Same dataset for all of them a real social-graph-shaped dataset from Stanford's SNAP collection, ~18.7k nodes and ~198k edges, sized specifically to fit inside every platform's free tier without anyone getting an unfair advantage. Same queries too: I wrote every single query 1-hop, 2-hop, 3-hop traversals, point lookups, filtered lookups, aggregations exactly once, then translated each one into whatever query language a given platform actually speaks. No platform ever got a "friendlier" version of a query than another.

And everyone ran under the same 0.5 vCPU / 256MB RAM ceiling, whether that was their real cloud free tier or a Docker container I capped by hand to match.

The one that didn't survive

Memgraph is genuinely well-regarded fast, in-memory, good reputation. It also crashed instantly, every single time I tried to start it, with a segfault. Not a config error. Not an out-of-memory kill. A segfault, before it had loaded a single byte of data.

I did what you'd hope someone benchmarking databases would do: I didn't just shrug and swap it out. I ruled things out one at a time. Was it the memory cap? Removed it entirely still crashed. The CPU limit? Same. A stale data directory from an earlier failed attempt? Started completely fresh still crashed. Seccomp restrictions from the container runtime? Disabled them entirely still crashed. A different Memgraph version, in case it was a recent regression? Tried an older one still crashed, identically.

Six variables, one at a time, all ruled out. Whatever's actually wrong lives somewhere below what I could see from inside a container, on this particular host. I'll be honest: I don't know exactly what it is. What I do know is that pretending it worked, or quietly swapping in a different database without saying why, would have been a worse choice than just... saying that. Sometimes a piece of infrastructure doesn't run on your machine, and the correct response is to document that clearly and move forward with what does.

The one that lost all its data

This one's my own fault, and I think that's worth saying plainly rather than dressing it up.

FalkorDB — the fastest database in this entire benchmark by a wide margin ran beautifully for hours. I loaded data, ran the full query suite, got great numbers. Then the environment I was working in restarted, as environments sometimes do, and I came back to find FalkorDB completely empty. Zero nodes. Zero edges. All of it, gone.

I'd set up a bind mount specifically so the data would survive a restart. It just... wasn't working, and the failure was silent no error, no warning, nothing. It took real digging to figure out why: FalkorDB's actual data directory inside the container isn't where most Redis-based images put it, so my mount was pointed at the wrong path entirely. And separately, the config flags I'd passed to enable disk persistence had been silently ignored — the container's settings said one thing, but the database itself was running with completely different defaults. Two independent bugs stacked on top of each other, and either one alone would have been enough to lose everything.

The fix, once I found it, was small: point the mount at the right place, and set the persistence config as a live command after the container starts instead of trusting it to apply automatically. But I only found any of this because I lost real data first. If this benchmark had been a real production setup instead of a testing environment, that's the kind of bug that costs someone their weekend.

The mystery I couldn't fully solve

Here's the one that's still bugging me, in a good way.

AuraDB — Neo4j's managed cloud offering — was, unsurprisingly, the slowest platform in almost every test. That part's not surprising; it's a real network hop to managed infrastructure, versus databases running right there in the same environment. What's genuinely odd is how it was slow. Every single query, from the most trivial possible operation (fetch one node by its exact ID) to the heaviest 3-hop traversal, took at least ~220 milliseconds. Not "roughly around" 220ms — a hard floor, almost exactly the same number, regardless of what the query actually asked for.

That's not what slow query execution looks like. That's what a fixed cost looks like something that happens on every single request no matter how simple, probably somewhere in how the connection gets authenticated or routed before your query even starts running. I didn't get to root-cause it fully, and I want to be honest about that rather than inventing a tidy explanation. But if I'm right, it means the thing to optimize for on AuraDB Free isn't your query complexity at all it's how many separate requests you're making, full stop.

The one where the numbers just don't make sense yet

CognoDB won almost every single benchmark. Fastest 1-hop lookups. Fastest point lookups. Fastest aggregations. Genuinely, consistently fast until one specific query, where it was suddenly the slowest database in the entire lineup, by more than 2.5x versus the next-worst option. Same query pattern, same dataset, same everything just one particular kind of query where CognoDB's numbers flipped completely.

I don't have a confirmed explanation. My best guess involves how that specific query chains several operations together in a way the others in this benchmark don't, and query planners can behave very differently on chained operations versus simple ones. But a guess is all it is, and I'd rather leave that as an open question in the data than manufacture a confident-sounding answer I can't actually back up.

What I'd actually tell someone picking a graph database

If you need raw speed and you're willing to run and operate the database yourself: FalkorDB, by a wide margin, assuming you can live with (and properly configure) its persistence model learn from my mistake there.

If you want zero operational burden and you're willing to pay a real, consistent latency tax for it: AuraDB does exactly what it says, predictably, every time the predictability might matter more to you than the raw number.

If you're evaluating CognoDB specifically: it's fast, competitive with self-hosted alternatives on almost everything, and worth taking seriously just go in aware that at least one query pattern behaves unexpectedly, and if that pattern matters to your use case, test it yourself before committing.

And if you're benchmarking anything under a tight resource budget: budget real time for things to break in ways you didn't expect. Two of five databases in this test failed in ways that had nothing to do with their query performance and everything to do with infrastructure quirks that only show up once you actually try to run something for real, under real constraints, instead of reading the marketing page.

Full methodology, every query definition, every raw result, and the complete reproducible benchmark harness are in the GitHub repo including the six-variable debugging trail for the Memgraph crash, if you're curious exactly what I ruled out.