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 w