Benchmark Results

LDBC SF1 Interactive Queries — 7-Database Comparison

3.18M nodes, 17.2M edges. All databases on identical LDBC SF1 dataset. Times are warm p50. Units: milliseconds.

IC5 is the key differentiator: multi-hop join with grouping. xrayGraphDB completes in 1.1ms where competitors need 78ms–3,017ms. IC11 and graph-specific queries are N/A for SQL databases that lack native traversal. Competitor server: 187GB RAM, 44-core Xeon Gold 6152, Tesla T4.

Apples-to-Apples: Same Vertex, Same Dataset, 7 Systems

BFS from vertex 71768986 (undirected degree 5,214). Friendster: 65.6M vertices, 1.8B edges. RTX PRO 6000 Blackwell (96 GB), 16 vCPU, 144 GB RAM. May 2026.

Vertex counts verified across systems: hop 1 = 5,214–5,215, hop 2 = 2,151,463 (exact match).

cuGraph is NVIDIA's GPU graph analytics library. It achieves 20 GTEPS on pure BFS — but cannot build an undirected Friendster graph on a single 96 GB GPU (cuDF CSV OOM, CSR sort OOM, int32 size_type limit). xrayGraphDB is a persistent graph runtime, not a BFS kernel. Different workload classes, honestly compared.

GPU Compute Engine Head-to-Head

Same RTX PRO 6000 Blackwell (96 GB VRAM). Same Friendster dataset. Courtroom-clean methodology.

*cuGraph BFS ran on directed-only graph (1.8B edges). cuGraph could not build undirected Friendster on 96 GB GPU due to: cuDF CSV parser OOM, CSR sort+symmetrize OOM, and cudf int32 size_type limit (3.6B rows > 2.1B max). cuGraph is optimized for specialized GPU graph kernels; xrayGraphDB is optimized for persistent relationship-intelligence workloads at billion-edge scale.

Sub-Second Betweenness Centrality on 3.6 Billion Edges

Friendster: 65.6 million vertices, 3.6 billion undirected edges. Approximate betweenness centrality (ABRA pair-sampled, ε=0.05) completed in 977 milliseconds (warm, production CPU). On the Blackwell GPU server (Docker): 5.1 seconds warm (ε=0.05), 1.5 seconds (ε=0.10).

Where xrayGraphDB Leaves Everyone Behind

What this measures: Starting from a single person in a social network, how many people can you reach at each degree of separation? Hop 1 = direct friends. Hop 2 = friends of friends. Hop 3 = three degrees out. By hop 4, you've touched 93% of the entire 65-million-person graph.

Why it's so hard: At each hop, the frontier explodes. Hop 3 adds 33 million new vertices. Hop 4 adds another 26 million. The system must track which of 65 million vertices have already been visited, expand every edge from millions of frontier vertices simultaneously, deduplicate the results, and do it all without running out of memory. Most databases crash, OOM, or timeout before hop 4.

xrayGraphDB solves this with a patent-pending native traversal engine. Frontier expansion happens directly against the resident graph — no query parser overhead, no per-call planning. Memory stays bounded as the frontier grows, and the storage layout keeps neighbor lookups cache-friendly even as the graph evolves. The result: full-graph traversal in 5.5 seconds where every competitor tested either crashed or timed out.

Friendster: 65.6 million nodes, 3.6 billion undirected edges. Blackwell GPU server (Docker container). Source: vertex 71768986 (degree 5,214).

Vertex counts verified across systems: hop 1 = 5,214–5,215, hop 2 = 2,151,463 (exact match between xrayGraphDB, Kuzu, and DuckDB). Same source vertex (71768986), same dataset, same hardware. Apples to apples.

Why competitors fail: Traditional databases use Cypher query planners that expand variable-length paths via depth-first search. At hop 3, the frontier is 33 million vertices — each with ~55 neighbors on average. That's 1.8 billion edge lookups in a single hop. DFS-based planners either explode in memory (tracking all paths) or degenerate into full table scans. Recursive CTEs (DuckDB, PostgreSQL) perform disjunctive joins against 1.8 billion rows per hop — each join slower than the last. In-memory databases (Memgraph) simply cannot hold 3.6 billion edges in RAM.

xrayGraphDB's patent-pending native traversal engine completed 15 hops on 3.6 billion edges in 5.5 seconds. This is not a synthetic benchmark — Friendster is a real social graph with extreme skew, giant hubs, and combinatorial frontier explosions.

Cypher BFS: 12.16 Billion Paths at Hop 9

Variable-length Cypher path expansion on Friendster. MATCH (p)-[:KNOWS*1..N]-(f) RETURN count(f) — raw path count, no DISTINCT. This is the combinatorial explosion that destroys every other database.

12.16 billion paths
Measured, not estimated. Cypher variable-length expansion. 28.4 minutes at hop 9.

Each hop multiplies the frontier by the average degree (~55). By hop 9, the path count exceeds 12 billion. No other database we tested survived past hop 4 on Friendster using Cypher-style path expansion. xrayGraphDB kept going — we stopped at hop 9 because the result was proven, not because the engine failed.

GPU-Accelerated Analytics

GPU analytics on Friendster (3.6B edges) using the RTX PRO 6000 Blackwell (96 GB VRAM, Docker container). GPU kernels compiled at startup — no CUDA toolkit dependency at runtime.

RTX PRO 6000 Blackwell Server Edition, 96 GB VRAM, SM 12.0, 188 SMs. Docker container. Triangle Count and K-Core dispatch to GPU; PageRank, WCC, Community, and BFS currently run on CPU. Triangle count verified against SNAP ground truth: 4,173,724,142 (exact match).

cuGraph — NVIDIA's own GPU graph library — could not even build the undirected Friendster graph on this same 96 GB GPU. xrayGraphDB ran all algorithms successfully.

Friendster: 3.6 Billion Undirected Edges, One Server

65.6 million vertices. 3.6 billion undirected edges. Loaded in 6.25 minutes at 1.8 million edges/sec. Full analytics suite completed. RTX PRO 6000 Blackwell (96 GB VRAM). May 2026.

BFS from vertex 71768986 (degree 5,214). Native frontier expansion against the resident graph. The graph is fully exhausted — 100% of vertices reached. We could keep going; there's nothing left to find.

5.505 seconds
15 hops. 65.6 million vertices. 3.6 billion edges. One server. Docker container. Graph exhausted.

The peak frontier explosion is at hops 3–4: 59 million new vertices discovered in two levels. That's 1.8 billion edge lookups per level, resolved in under a second each. We stopped at hop 15 because the graph was exhausted — not because the engine couldn't continue.

10-hop BFS on 3.6 billion edges: not feasible for everyone else. xrayGraphDB: 476ms.

Friendster Analytics Suite — Three Servers

65.6M vertices, 3.6B undirected edges. Three servers tested: Blackwell GPU (Docker container, 96GB VRAM, 16-core EPYC), Production CPU (503GB, 64-core EPYC, bare-metal), and Budget (62GB, T1000 8GB). The Blackwell numbers are from a Docker container — zero overhead verified. Even the budget server completes analytics that no competitor can attempt on any hardware.

Triangle count verified against SNAP ground truth: 4,173,724,142 triangles (exact match). Blackwell column is a Docker container — not bare-metal. Zero Docker overhead verified. BC uses the ABRA pair-sampled algorithm. First call initializes; subsequent calls are faster.

38-second triangle count on 3.6 billion edges. GPU at 85%. SNAP-verified exact match.

*We tested 7 competitors on the same Blackwell hardware with the same Friendster dataset. None completed these workloads under the tested single-GPU configuration: cuGraph (OOM building undirected graph), Kuzu (hop 3 timeout), DuckDB (hop 2 timeout), Neo4j (hop 4 timeout), Memgraph (OOM loading), GraphBLAS (OOM during BFS). All scripts and logs published at github.com/eMTAi-Labs/xraygraph-bench.

Data Loading Speed Comparison

LDBC SF1 dataset. Measured on competitor server (187GB RAM, 44-core Xeon Gold 6152). xrayGraphDB Friendster on .187 (503GB RAM, 64-core EPYC).

DuckDB is legitimately fast at bulk ingest — it is a columnar analytics engine optimized for COPY. Graph databases (Neo4j, Memgraph) are 10–100x slower at loading due to index maintenance during insert.

Docker Performance — Zero Overhead

Docker container vs bare-metal on identical hardware and dataset. No performance penalty.

Docker uses Linux namespaces and cgroups — no hypervisor, no VM overhead. The 0.24ms vs 0.47ms difference is TCP stack variance, not container overhead.

xrayProtocol vs Bolt — Same Database

xrayGraphDB v4.9.5, same queries, same data. Bare-metal measurements.

xrayProtocol p50 for RETURN 1: 0.47ms (bare-metal). Bolt overhead is approximately 2x on trivial queries. The gap widens dramatically on result-heavy queries (LIMIT 100: 17.6x) due to columnar serialization.

Cross-Database Comparison — LiveJournal (4.8M nodes, 69M edges)

Protocol: Bolt (common denominator for fair comparison)

Data load: xrayGraphDB 1.4s (Persistent graph store) vs Memgraph 9,668s (failed at 150K of 69M edges)

Competitor Limitations at Friendster Scale

We tested every major graph database, GPU compute engine, and analytics library on Friendster (65.6M vertices, 1.8B edges) with the same Blackwell GPU hardware. Results published transparently — including wins AND failures.

All scripts, logs, and raw data available at github.com/eMTAi-Labs/xraygraph-bench. Methodology: same hardware, same dataset, same source vertex. Wins AND losses published.

Where the Speed Comes From