Run the graph database benchmark yourself

Published 01/11/2026

We have published the benchmark we use to compare Galactus DB with Neo4j and Memgraph. It is one Python script and one Compose file, Apache-2.0, at github.com/galactusdb/galactus-db-benchmark. Clone it, run one command, and it measures all three engines on your machine and writes the results as CSV and a single page of charts. Every number in this post came from that code, and you can check every one of them.

git clone https://github.com/galactusdb/galactus-db-benchmark
cd galactus-db-benchmark
pip install -r requirements.txt
python bench.py && python report.py

How the suite keeps it even

• One engine at a time. Each engine starts on a fresh volume, runs every workload and is removed before the next one starts. The order rotates on each of the three passes, and we report the median.
• The same limits for everyone. Two profiles, applied identically to every container: 8 CPUs with 4 GB of memory, and 2 CPUs with 1 GB.
• Community editions on their defaults. Galactus DB 2.1.8 runs its published image as it ships, including buffered durability with a 50 ms commit-log sync. Neo4j 5.26.32 Community gets the heap and page cache that Neo4j's own neo4j-admin server memory-recommendation prints for each limit (2 GB heap and 512 MB page cache at 4 GB; 307 MB and 52 MB at 1 GB), plus the Graph Data Science plugin for weighted paths. Memgraph 3.14.0 runs its defaults with telemetry switched off.
• Same client, data and Cypher. One Python process drives every engine through the official Neo4j Python driver 5.28.1. The graph comes from a fixed seed: 100,000 people, each knowing two others, with a weight from 1 to 10 on every relationship. Every engine runs the same statement wherever it accepts it. Memgraph has no shortestPath() or Graph Data Science, so it runs its own *BFS, *ALLSHORTEST and *WSHORTEST.
• The same answers. Every timed query's answers are fingerprinted. In both profiles, all four engines returned identical answers for every workload.
• Failures count. When an engine runs out of memory, the workload is recorded as did not finish, with the reason, and the run carries on.

Galactus DB runs twice. Paged is its default engine: it opens a database straight from disk and keeps the pages in use in memory. Resident keeps the whole graph in memory, the same model as Memgraph.

The machine: an Intel Core i9-13900K with 64 GB of RAM, Windows 11 with Docker Desktop 28.0.1 on WSL2, Python 3.10. Images by digest: Galactus DB 2.1.8 sha256:50b294cc…, Neo4j 5.26 Community sha256:249a1ec6…, Memgraph 3.14.0 sha256:a7324212…. Measured on 01/11/2026.

Shortest paths

Finding the route between two things is the heart of most graph work, from GraphRAG to fraud rings to supply chains. The unweighted tests pick two people up to 6 hops apart. The weighted test runs Dijkstra between two random people over the relationship weights; Galactus DB and Neo4j answer it with the same gds.shortestPath.dijkstra.stream call on a projection built once.

Galactus DB found the shortest path in about a third of Neo4j's time and a quarter of Memgraph's, and all shortest paths in about 40% of Neo4j's time and a seventh of Memgraph's. On weighted paths it finished in 23.5 ms against 26.1 ms for Neo4j and 417 ms for Memgraph. Galactus DB 2.1.8 stops a single-target Dijkstra as soon as it reaches the target and keeps the weighted adjacency with the projection, which took this call from 105 ms in 2.1.7 to 23.5 ms.

Lookups and traversals

Index lookups take half a millisecond on Galactus DB and Memgraph, and about 2.5 times as long on Neo4j. Memgraph answered friends of friends 0.03 ms sooner than Resident. The filtered scan reads all 100,000 people: Resident did it in 8.3 ms, Memgraph in 10.4 ms, Neo4j in 14.9 ms and Paged in 26.2 ms. With 16 clients reading together, Paged served the most lookups per second, 37% more than Neo4j.

Memory

With the graph loaded, Resident used 89 MB: a thirty-fourth of Neo4j's memory and about a third of Memgraph's. Paged used 164 MB. Under 16 clients reading at once, Memgraph peaked lowest at 415 MB, against 524 MB for Resident, 612 MB for Paged and 3,174 MB for Neo4j.

Loading and start-up

Galactus DB loaded nodes faster than both, and Resident loaded 82,156 relationships a second, 2.3 times Neo4j's rate. Paged loaded relationships at 55,285 a second, behind Memgraph's 73,854. After a clean stop, Galactus DB answered its first query in under 0.8 s, Memgraph in 1.1 s and Neo4j in 14.9 s.

With 2 CPUs and 1 GB

The second profile gives every engine a quarter of the CPUs and a quarter of the memory: the size of a small cloud instance or a database sharing a server with its application.

With a quarter of the resources, Galactus DB kept its memory use, its load rates and its weighted paths where they were at 4 GB. Its largest changes were Paged's filtered scan, from 26.2 ms to 30.1 ms, and Resident's shortest path, from 0.53 ms to 0.62 ms. Neo4j sat at its 1 GB limit with the graph loaded and was killed for running out of memory on every weighted path pass and on two of the three concurrent read passes. Memgraph served the most concurrent reads at 1 GB, 3% more than Galactus DB.

Run it on your own machine

The suite pins every image version in its Compose file, records each image digest and each server's effective settings next to the results, and prints every statement each engine ran in its report. Change the scale, the number of passes or the limits with one option each, and send us what you find.

For the side-by-side detail on each engine, including the workloads this suite does not cover, see Galactus DB compared with Neo4j and Galactus DB compared with Memgraph.