gDown Performance

Median latency in milliseconds (lower is better), Bolt against Bolt with the same Java driver, no index unless stated. 100,000 nodes and 1,000,000 relationships; Apple M4 Max, Docker containers limited to 4 CPUs and 8 GB; Gluonify on the JVM against neo4j:5.26-community.

Over 16 workloads, Gluonify is faster on 14, level on 1 (first 10 rows) and slower on 1 (3 distinct hops). The geometric mean of the latency ratios is 1.7.

Limits: one machine, one run per configuration (±10 % or more on medians); one Gluonify node against one Neo4j Community, so the cost of 3-node replication is not measured; a dataset that fits in RAM; OIDC/TLS disabled during the run. The disk-size comparison (170–194 MB against 836 MB) is not like for like.

Source: gluonify-gdown, docs/BENCHMARK.md (6th round, Java 25) and README. Figures are reproduced from those documents, not re-measured for this page.

Startup, memory, CPU and size

Same machine and same limits for both: a fresh Docker container with 4 CPUs and 2 GB of memory, default settings. Startup: from launching the container to the first answered query (median of 5). Load: 50,000 nodes, then 8 clients read one node by id for 20 seconds through each product's HTTP API.

gDown starts in 2.3 s against 5.2 s, idles at 167 MiB against 414, and serves 9,951 reads per second against 2,550 in the same container, which is 3,741 requests per CPU-core second against 691. Its executable is 121 MiB; the Neo4j image is 965 MiB.

Limits: one Apple Silicon machine under Docker, one run (5 startups), Neo4j with the official image's default settings (heap chosen by the JVM in a 2 GB container) over its HTTP Query API, gDown over its own HTTP API; a simple read workload, not a sizing test. gDown's startup includes the election of its single-member Raft group. The sizes are not strictly like for like: one executable against an image that also holds a JVM.

Source: gluonify-chamber, scripts/bench-footprint.py; raw results in gluonify-codex, bench/footprint-2026-10-05.json.

LDBC SNB Interactive

The 29 queries of the LDBC Social Network Benchmark Interactive workload (14 complex reads, 7 short reads, 8 updates; Apache 2.0, unchanged) all run on a generated graph with the SNB schema.

  • 29 / 29 queries run: 14 complex reads, 7 short reads, 8 updates
  • 3 / 3 members of a 3-node cluster return the same row counts for the 21 reads
  • 18 ms median write while the leader takes 1,365 acknowledged writes (3,000 persons)
  • 0 ms median read on a follower during those writes (95th percentile: 30 ms)

Complex reads: median latency in ms

  • complex-1 : 1 ms
  • complex-2 : 2 ms
  • complex-3 : 10 ms
  • complex-4 : 0 ms
  • complex-5 : 4 ms
  • complex-6 : 4 ms
  • complex-7 : 24 ms
  • complex-8 : 0 ms
  • complex-9 : 23 ms
  • complex-10 : 6 ms
  • complex-11 : 1 ms
  • complex-12 : 2 ms
  • complex-13 : 0 ms
  • complex-14 : 0 ms

300 persons, 8,569 nodes, 45,002 relationships; 5 persons per read. Short reads: median 0 ms. Updates: 3 to 6 ms.

At 3,000 persons (90,000 nodes and 470,000 relationships, loaded through Raft in 16 s), medians stay under 60 ms except complex-7 (0.2 s). Two optimisations found by this test: complex-1 went from 0.6 s to 34 ms, complex-14 from 2 s to 8 ms.

The data is generated by the test, not by the LDBC Datagen: the times are not comparable with published LDBC results. One run per configuration. The test also found two defects, now fixed.

Source: gluonify-gdown, README and the reports of LdbcSnbTest and LdbcClusterTest.