Galactus DB and Neo4j: a tale of two graph databases

Published 17/09/2026

A graph database has a varied working day: find a person, follow a few connections, load a batch of records, then do it all again while everyone else is asking questions too. How do Galactus DB and Neo4j compare at those jobs? Here are the scores, with a little context to help you read them.

Galactus did well on batch loading, indexed lookups and memory footprint. Neo4j led on the filtered scan and on single-client commits when both engines waited for disk. There is plenty to like here, and the workload matters.

Before we open the scorecard

These results are a snapshot from 17 September 2026, comparing Galactus DB with Neo4j 5.26.30 Community. They describe those builds, rather than promising what any future latest tag will do.

Both databases handled the same graph: 100,000 people, 200,000 KNOWS relationships and an equality index on Person.id. The application queries and parameters were identical, sent over Bolt with the same Python client and Neo4j driver. Results below use medians from three passes.

Each container had an allowance of 8 CPUs and 8 GB RAM. Galactus used its published image defaults; Neo4j had a 2 GB heap and 2 GB page cache. The host was an i9-13900K with 64 GB RAM, running Docker Desktop on Windows 11/WSL2. Those settings matter, especially when reading the memory figures.

There is also a choice hiding inside the word "committed". Galactus defaults to buffered durability: it acknowledges the log append before a scheduled disk sync. Recent writes can be lost on a power or operating-system failure. Group mode waits for a shared disk flush before acknowledging a commit, as the tested Neo4j setup also did. We show both Galactus modes so that the extra speed from waiting less is visible, rather than buried in a footnote.

Bringing in the graph

Imports reward batching: give the database a useful chunk of work each time you ask it to commit. Everyday writes have a different rhythm, so the table also includes individual commits and several clients writing together.

For latency, lower is better; for throughput, higher is better. The p50 is the median latency, while p99 gives a view of the slower end of the requests.

Buffered Galactus loaded nodes at about 1.9 times Neo4j's rate and relationships at 2.2 times its rate. Group mode kept a loading advantage too, at about 1.5 and 1.6 times respectively, while waiting for disk.

For a single client making individual durable commits, Neo4j had the lower median latency: 3.88 ms against 4.79 ms for Galactus group mode. That is a useful reminder to look at the row that resembles your application.

When everybody turns up at once

Group commit has more to share when more writers are active. At 64 clients, Galactus group mode reached 3,623 writes/s against Neo4j's 3,091, with p99 latency of 38.2 ms against 41.8 ms. Buffered mode reached 4,054 writes/s, although its p99 was higher at 47.8 ms.

More clients do not automatically mean more throughput. Buffered Galactus stayed around the same write rate as concurrency increased, so piling more requests into the queue would not buy much extra capacity in this setup.

Finding things and following connections

An indexed lookup is the database equivalent of knowing which drawer to open. A traversal follows the connections from there. A scan has a bigger job: look through the people and check which ones match.

Indexed lookups and short traversals took about half as long on Galactus with this dataset and client. The shortest-path query also favoured Galactus, at 1.06 ms against 1.36 ms.

Neo4j was about 2.5 times faster on the filtered scan. That query was MATCH (p:Person) WHERE p.age % 7 = 0 RETURN count(p): a good example of why a quick lookup and a full scan deserve separate rows on the scorecard.

With concurrent readers, Galactus delivered more seeks per second at both client counts. As with writes, its throughput stayed broadly level as the number of clients increased.

Leaving room for the application

A database shares its home with application code, background jobs and all the other things a server gets asked to do. Memory footprint is part of that conversation too.

These are peak container-memory readings from docker stats. Galactus reached about 400 MB during writes with this graph. Neo4j's figures reflect its configured heap and page cache; a smaller heap would change the comparison. Neither column is a minimum memory requirement.

Galactus keeps graph structure and indexes in memory, so allow for growth as your graph gets bigger. A small footprint on this dataset is useful evidence, not a promise that every graph fits in the same space.

Which rows matter to you?

For batch imports, short traversals and indexed reads, these results give Galactus plenty to smile about. If your application spends its day scanning whole labels or issuing individual durable commits, those rows deserve just as much attention.

This comparison covers a graph that fitted in memory and single-instance operation. It does not assess larger-than-memory datasets, clustering, Neo4j Enterprise or the wider tooling around either database. Different hardware, settings and query mixes can change the results.

For a closer look at the write trade-off, see the durability guide. For the download and idle-memory comparison, see a graph database that packs light.

Neo4j is a registered trademark of Neo4j, Inc. Galactus DB is not affiliated with Neo4j, Inc.