GTP2025 Graphistry Keynote: 2B-Edge Graphs in 2 Seconds – Unlock GPU Power with GFQL

Figure: Benchmarking 2B edge graph queries running in 2s on a H100

Major GFQL Updates from Graph the Planet Keynote

I want to share some thoughts about the second half of my Graph the Planet keynote. We have been releasing fairly major updates to GFQL, our new open-source graph dataframe query language designed for both CPU and GPU modes, and understanding what they unlock can be quite useful.

GFQL is becoming commonly used across our customer projects – from cybersecurity and fraud to finance and legal. Likewise, is part of the magic powering new features such as the collections panel. Just as DuckDB is becoming popular for transforming tabular data workflows for data in the KBs – GBs size range, GFQL is making graph computing simpler and faster for those same scales and scenarios. Think about all that data wrangling that happens as soon as you want to do anything graph-y in data web apps, dashboards, notebooks, ETL pipelines, AI+ML pipelines, and visualizations.

Yes in theory round-tripping with external graph database infra for every little thing is possible, but similar to Pandas and DuckDB often making sense over Spark and BigQuery, always using a Graph DB is overkill, and doubly painful if you have to redo your infra for that.

The most exciting recent developments in GFQL are two architectural breakthroughs:

First, we’ve introduced the new remote modes that enable your code to seamlessly offload intensive graph computations to your Graphistry GPU box – perfect for processing larger-scale database extracts in your ETL pipelines that are too slow in CPU mode. You can push data to Graphistry or GFQL / GPU Python, make Graphistry pull it, or use data already on the server like your visualizations – we’re finding all three modes unlock new workflows in practice.

Second, we are measuring performance strides for big graphs. The result is you can go after bigger graphs, keep things snappy at bigger scales… and not crash with out-of-memory errors. A small and cheap T4 GPUs efficiently manage over 100 million edges, while a modern H100 GPUs smashes through billions. We were stunned to see H100 execution times remain within seconds.

GFQL on GPUs: It Just Works

We demonstrated GFQL handling graph queries at surprising scales, all on a single GPU:

• 1M–100M edges: sub-second queries (T4 GPU)
• 1B edges: queries within a minute – and without crashing (T4 GPU)
• 2B edges: queries in about 2 seconds (H100 GPU)

No query changes required:

g2 = g1.chain(query, engine=”cudf”)  #  GPU-ready

Unified Memory: Tackle Graphs Bigger Than GPU RAM

Graphs bigger than memory are frustrating because they used to take a lot of work to avoid crashes. We showcased handling graphs much larger than GPU memory using Nvidia’s Unified Memory and found the performance to be pretty incredible. Our demos include:

• T4 GPU (16GB, $0.25/hr): Handled up to 1.6B edges without crashing
• H100 GPU (80GB, $2.50/hr): Smoothly handled 2B edges

The big idea is to let the GPU spill to CPU memory, which is typically bigger and cheaper. GFQL can now handle graphs that are 2-10X bigger than otherwise possible with engines limited to GPU memory size.

Set-up is straightforward, just run this before GPU code:

GFQL’s GPU engine is built to be RAPIDS-native, so you get to benefit from the RAPIDS ecosystem like the RAPIDS Memory Manager (rmm).

GFQL Remote Mode: GPU-as-a-Service

GFQL remote mode introduces two flexible ways to run code from anywhere—whether your data is already in Graphistry, being uploaded, or pulled from elsewhere on-the-fly:

• Ad hoc mode: Push GFQL queries or GPU Python scripts directly from notebooks, dashboards, or pipelines
• Named endpoint mode: Save reusable endpoints—a REST-style variant of database stored procedures—for recurring queries or agent workflows

Both modes support:

• GPU-powered GFQL graph queries: Already live on Hub
• Full GPU Python for graph ETL and analytics: Enterprise-only

You can even target data from existing Graphistry visualizations or bring your own via upload or remote source (e.g., S3, database).

Example:

Benefiting from GPU acceleration and Remote Execution

• Scale efficiently: 2–10X larger graphs on the same hardware
• Reduce compute costs: Replace expensive CPU clusters with affordable and multi-use GPU instances
• Easy operations: Call REST endpoints and push queries from notebooks or pipelines without the GPU infra headaches 
• Increase flexibility: Target local and remote data, run queries and full GPU Python, and do more with existing Graphistry viz, all from anywhere

To start using GFQL:

Then checkout the guides and demo notebooks at https://pygraphistry.readthedocs.io/en/latest/

(For GPUs, install a Nvidia RAPIDS runtime, or get a free Graphistry Hub account, or quick launch your own hosted Graphistry server)

Our goal remains making GPUs accessible and impactful for investigative workloads, enabling analysts and engineers to tackle previously out-of-reach workloads with ease.

Reach out if you’d like to dive deeper into GFQL and GPU-powered graphs!