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 |
|
|
|
|
|
|
GFQL polars-gpu |
q2 |
|
|
|
|
|
|
GFQL polars-gpu |
q3 |
|
|
|
|
|
|
Memgraph |
q4 |
|
|
|
|
|
|
Kuzu |
q5 |
|
|
|
|
|
|
GFQL polars |
q6 |
|
|
|
|
|
|
GFQL polars |
q7 |
|
|
|
|
|
|
GFQL polars |
q8 |
|
|
|
|
|
|
GFQL polars |
q9 |
|
|
|
|
|
|
GFQL polars-gpu |
The 100,000-person board#
Query |
Kuzu |
Memgraph |
Neo4j |
GFQL pandas |
GFQL polars |
GFQL polars-gpu |
Fastest |
|---|---|---|---|---|---|---|---|
q1 |
|
|
|
|
|
|
GFQL polars-gpu |
q2 |
|
|
|
|
|
|
GFQL polars-gpu |
q3 |
|
|
|
|
|
|
GFQL polars |
q4 |
|
|
|
|
|
|
GFQL polars |
q5 |
|
|
|
|
|
|
Memgraph |
q6 |
|
|
|
|
|
|
Memgraph |
q7 |
|
|
|
|
|
|
Memgraph |
q8 |
|
|
|
|
|
|
Kuzu |
q9 |
|
|
|
|
|
|
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 |
|
|
|
|
|
GFQL polars |
message content |
|
|
|
|
|
GFQL polars |
message creator |
|
|
|
|
|
GFQL polars |
recent replies |
|
|
|
|
|
Neo4j |
message replies (GFQL and Kuzu only) |
|
|
|
— |
— |
GFQL polars |
new topics (GFQL and Kuzu only) |
|
|
|
— |
— |
GFQL polars |
SF1#
Query |
GFQL polars |
GFQL pandas |
Kuzu |
Neo4j |
Memgraph |
Fastest |
|---|---|---|---|---|---|---|
seed lookup |
|
|
|
|
|
GFQL polars |
message content |
|
|
|
|
|
GFQL polars |
message creator |
|
|
|
|
|
GFQL polars |
new topics (GFQL and Kuzu only) |
|
|
|
— |
— |
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#
Choose an engine: Choosing a GFQL Engine: pandas, Polars, cuDF, Polars-GPU.
Lookups from known nodes: Indexing Guide.
Speedup case study: Speedup Case Study: Cypher + PageRank, GFQL vs Neo4j + GDS.
Explore GFQL: 10 Minutes to GFQL. Get started: 10 Minutes to PyGraphistry.