GFQL outperforming traditional graph databases#

We measured GFQL’s CPU and GPU optimized lazy dataframe approach to frequently outperform graph databases on popular benchmarks at different sizes, for both low-latency search scenarios and large analytical ones.

Choose an engine#

GFQL runs queries on pandas and polars on CPU, or cudf and polars-gpu with NVIDIA GPU support. The default engine='auto' selects from the input frames. Supported queries return the same rows across engines. On the graph-benchmark boards below, the Polars engine is faster than pandas on all queries at 100,000 people, by up to 52.7x (q5). See Choosing a GFQL Engine: pandas, Polars, cuDF, Polars-GPU for the selection guide.

g.gfql(query)                    # engine='auto': follows the input frames
g.gfql(query, engine='polars')   # columnar CPU execution

graph-benchmark: GFQL, Kuzu, Memgraph, and Neo4j#

The nine queries from prrao87/graph-benchmark rank nodes by degree, group and filter records, and count two-hop paths on synthetic social graphs with 20,000 and 100,000 people.

GFQL on CPU already answers these queries in milliseconds, so GPU mode has little to gain on workloads this small.

At 20,000 people, GFQL Polars is faster than Kuzu on 8 of 9 queries, than Memgraph on 8 of 9, and than Neo4j on all. At 100,000 people the counts are 8 of 9 (Kuzu), 6 of 9 (Memgraph), and all (Neo4j).

The 20,000-person board#

Query

Kuzu

Memgraph

Neo4j

GFQL pandas

GFQL polars

GFQL polars-gpu

Fastest

q1

14.93 ms

66.08 ms

74.50 ms

27.09 ms

6.89 ms

6.05 ms

GFQL polars-gpu

q2

27.08 ms

44.41 ms

67.74 ms

28.77 ms

9.97 ms

9.58 ms

GFQL polars-gpu

q3

5.88 ms

4.16 ms

8.31 ms

10.07 ms

4.78 ms

4.49 ms

Memgraph

q4

3.06 ms

6.38 ms

11.54 ms

8.73 ms

3.19 ms

4.53 ms

Kuzu

q5

4.89 ms

4.63 ms

18.33 ms

77.27 ms

2.82 ms

7.20 ms

GFQL polars

q6

7.46 ms

4.85 ms

20.99 ms

78.47 ms

3.27 ms

7.04 ms

GFQL polars

q7

6.06 ms

5.39 ms

15.14 ms

18.19 ms

2.51 ms

7.45 ms

GFQL polars

q8

2.72 ms

198.80 ms

198.71 ms

7.41 ms

2.11 ms

2.50 ms

GFQL polars

q9

10.64 ms

124.91 ms

422.29 ms

16.10 ms

7.08 ms

6.60 ms

GFQL polars-gpu

The 100,000-person board#

Query

Kuzu

Memgraph

Neo4j

GFQL pandas

GFQL polars

GFQL polars-gpu

Fastest

q1

141.36 ms

655.50 ms

680.72 ms

167.52 ms

26.00 ms

17.97 ms

GFQL polars-gpu

q2

247.44 ms

468.94 ms

632.70 ms

172.07 ms

35.10 ms

27.02 ms

GFQL polars-gpu

q3

23.60 ms

30.17 ms

51.14 ms

70.37 ms

8.92 ms

9.51 ms

GFQL polars

q4

10.42 ms

37.64 ms

63.76 ms

62.84 ms

7.81 ms

9.92 ms

GFQL polars

q5

12.41 ms

3.95 ms

8.96 ms

403.62 ms

7.66 ms

13.67 ms

Memgraph

q6

16.53 ms

5.14 ms

22.94 ms

406.50 ms

8.67 ms

14.53 ms

Memgraph

q7

7.83 ms

3.74 ms

140.18 ms

114.20 ms

5.66 ms

13.80 ms

Memgraph

q8

9.10 ms

7316.46 ms

3766.74 ms

78.05 ms

13.27 ms

177.64 ms

Kuzu

q9

80.25 ms

6199.80 ms

4843.46 ms

141.98 ms

37.53 ms

23.72 ms

GFQL polars-gpu

SNB Interactive#

These queries come from the LDBC Social Network Benchmark Interactive workload. They run on SF0.1 and SF1 datasets.

GFQL outperforms Kuzu, Memgraph, and Neo4j across the SNB Interactive tables at both SF 0.1 and SF 1; the one exception is recent replies at SF 0.1, where GFQL and Neo4j are level. At SF1, message content and creator lookups take 0.163 ms and 0.231 ms, respectively. Polars is also faster than Kuzu on every eligible query in these tables, including message replies and new topics. The tables show each engine’s result for the profile lookup and recent replies as well.

SF0.1#

Query

GFQL polars

GFQL pandas

Kuzu

Neo4j

Memgraph

Fastest

seed lookup

0.222 ms

0.914 ms

2.277 ms

3.166 ms

0.460 ms

GFQL polars

message content

0.162 ms

0.415 ms

0.658 ms

1.445 ms

0.489 ms

GFQL polars

message creator

0.220 ms

0.616 ms

1.318 ms

1.339 ms

0.462 ms

GFQL polars

recent replies

5.500 ms

27.275 ms

32.884 ms

5.425 ms

6.333 ms

Neo4j

message replies (GFQL and Kuzu only)

1.326 ms

11.872 ms

23.712 ms

—

—

GFQL polars

new topics (GFQL and Kuzu only)

38.387 ms

72.293 ms

48.082 ms

—

—

GFQL polars

SF1#

Query

GFQL polars

GFQL pandas

Kuzu

Neo4j

Memgraph

Fastest

seed lookup

0.276 ms

1.136 ms

1.956 ms

3.082 ms

0.453 ms

GFQL polars

message content

0.163 ms

0.425 ms

0.336 ms

2.060 ms

0.527 ms

GFQL polars

message creator

0.231 ms

0.632 ms

1.490 ms

1.871 ms

0.516 ms

GFQL polars

new topics (GFQL and Kuzu only)

155.497 ms

571.911 ms

217.133 ms

—

—

GFQL polars

How GFQL is fast, and when it is not#

GFQL joins tables of nodes and edges in batches instead of following one path at a time, over columnar frames based on Apache Arrow. Polars combines operations into lazy query plans to reduce intermediate work. cuDF and Polars GPU use NVIDIA GPUs for columnar operations. That favors bulk work: multi-join analytics, expansion from many starting nodes, and full-graph aggregation. For small results, GFQL uses indexed lookups and direct row selection to avoid work over the whole graph. The SNB tables measure those paths alongside larger queries.

Start on CPU with no special hardware, and move to a GPU engine by changing one keyword when the graph or result becomes large. The speedup case study measures a full filter, PageRank, filter pipeline on CPU and GPU against Neo4j + GDS, and GFQL vs Apache Spark GraphFrames on One Node measures filters, traversals, and PageRank against Spark GraphFrames.

Note

Same-path constraints (where) can be more expensive on dense graphs. Prefer selective per-step predicates and see GFQL WHERE (Same-Path Constraints) for details.

Provenance#

Run dates and hardware.

Measurement

Measured:

2026-10-03

Host:

dgx-spark (NVIDIA GB10), 20 CPU

Notes:
  • SNB-derived queries: 8 warmups and 31 fully materialized executions per process, repeated in 3 processes. Values are medians of process medians; query results match across systems.

  • GFQL builds adjacency and property indexes before timing. Index use is checked per query.

  • The measured bindings and seeded-lookup improvements apply to Polars.

  • Comparator measurements are from 2026-09-13.

Next steps#