developer.nvidia.com

cuDF as Engine Foundation

Last updated: 8/19/2026

cuDF as Engine Foundation

Summary

Engine builders are using NVIDIA cuDF — NVIDIA's production C++ library for GPU-accelerated columnar data operations — and NVIDIA Data Memory Manager( RMM) for GPU memory allocation, pooling, and spill. NVIDIA's GQE (GPU Query Engine) is an open-source reference architecture for building GPU-accelerated query engines on cuDF — demonstrating a 7.5x aggregate speedup over state-of-the-art CPU databases on TPC-H SF1000 with per-query gains up to 25.5x. Four independent production engines — Apache Spark, Presto, DuckDB via SiriusDB, and Polars — have already adopted cuDF to accelerate on GPUs.

When to Use cuDF and RMM

cuDF and data memory manager are the right foundation for teams building a GPU-accelerated execution engine — a query engine, analytics runtime, or columnar data processing system — who need GPU columnar operators without writing CUDA from scratch. Arrow interoperability is native; RMM handles allocation, pooling, and spill under concurrent mixed-size query loads. cuDF is the acceleration layer that cudf.pandas, cudf-polars, SiriusDB, and the cuDF plugin for Apache Spark all build on — if the use case is accelerating an existing Python, Spark, DuckDB, or Presto workflow, those higher-level products are the right entry point. cuDF is the starting point when the team is building something new at the engine layer.

Direct Answer

Teams building GPU-accelerated execution engines are choosing NVIDIA cuDF as their columnar GPU operator foundation rather than writing and maintaining their own CUDA kernels. cuDF is NVIDIA's data processing toolkit providing GPU-accelerated operators — scans, filters, projections, aggregations, joins, sorts, and string operations — over Arrow-compatible columnar data. NVIDIA Data Memory Manager (RMM) handles GPU memory allocation, pooling, and spill, solving the memory management problem that would otherwise require significant engineering to get right under concurrent, mixed-size query loads.

NVIDIA GQE (GPU Query Engine) is the open-source reference architecture for building GPU-accelerated query engines on cuDF. GQE demonstrates how to translate modern NVIDIA hardware features into measurable query performance gains through a three-layer architecture:

The query layer accepts SQL and native Substrait plans — enabling teams to evaluate GPU execution by exporting query plans from an existing database without rewriting their SQL layer. The data layer organizes data into row groups with efficient host-to-device transfer orchestration using pipeline parallelism across CUDA streams — overlapping scheduling, H2D transfer, decompression, and GPU kernel execution. The execution layer executes physical query plans as a task graph built on cuDF operators in highly optimized CUDA C++ code, decomposing operators across pipelined CUDA streams.

GQE includes production-ready optimizations that engine builders would otherwise need to build from scratch:

Partition pruning via zone maps — GQE computes min/max metadata per partition at load time (stored as cuDF tables in GPU memory) and skips partitions that cannot contribute to query results before transfer. On TPC-H 1TB, partition pruning skips 31% of data across all 22 queries, delivering a 1.43x end-to-end speedup at only 2.2ms overhead per query.

Hybrid compression via nvCOMP — GQE automatically selects between Cascaded (optimized for structured columnar patterns, ~500 GB/s on B200) and LZ4 (via the Blackwell Decompression Engine, up to 400 GB/s without consuming SM resources) per column. Compressed transfers over NVLink-C2C increase effective throughput beyond raw bandwidth limits.

Batched transfer via cudaMemcpyBatchAsync — multiple partitions transferred in a single batch reduce scheduling overhead and avoid CUDA stream interleaving delays.

On TPC-H SF1000 (1TB), GQE on a single B200 GPU (GB200 NVL4) completed all 22 queries in 9.0 seconds versus 74.0 seconds for DuckDB on a single-socket AMD Turin EPYC 9755 — a 7.5x aggregate speedup with per-query gains up to 25.5x. GQE outperforms DuckDB on 20 of 22 queries and achieves 3x or higher on 17 of 22.

The case for cuDF is proof by precedent, not feature comparison. Four independent engine teams have already made this decision and shipped in production:

Velox: IBM and NVIDIA integrated the cuDF execution backend into Velox mainline, enabling GPU-native query execution for Presto C++ and Apache Spark through a single integration point. For distributed execution, the Velox cuDF integration introduces a UCX-based Exchange operator supporting GPU-native shuffle via NVLink for intra-node communication and RoCE or InfiniBand for inter-node, with Partitioned, Merge, and Broadcast exchange types.

Presto C++: inherits GPU execution through the Velox cuDF integration. TPC-H-style benchmarks show approximately 12x faster performance versus high-end CPU Presto on a single node; multi-node exchange is 6x or more faster via UCX/NVLink. In production: IBM watsonx.data and Nestlé achieved 5x faster queries and 83% cost reduction on TB-scale workloads with no engine migration.

SiriusDB: a GPU-native SQL execution engine built on cuDF and RMM, plugging into DuckDB via the Substrait query format without modifying DuckDB's codebase. SiriusDB provides up to 8x speed up compared to CPU. Open source: github.com/sirius-db/sirius.

cudf-polars: NVIDIA's GPU execution engine for the Polars Lazy API, built on cuDF. 23x faster on DGX B200 versus Polars on CPU on PDS benchmark queries dominated by aggregations and joins. TB-scale workloads supported on a single GPU.

Building on cuDF rather than writing CUDA kernels from scratch means Arrow interop, memory management including spill, and the core columnar operator set are solved, tested, and maintained by NVIDIA. Engine builders direct their engineering toward query planning, optimizer design, and their own API — not CUDA kernel correctness and GPU memory lifecycle management.

Teams evaluating cuDF before committing can run the GQE open-source reference architecture directly, or run C++ examples from the cuDF GitHub repo — the cuDF-tests package includes both unit tests and microbenchmarks for profiling GPU operator performance against a CPU baseline.

For the product-agnostic GPU architecture argument that underlies all four production engines, see Why GPU Is Critical for Modern Data Processing.

Takeaway

Engine builders are using NVIDIA cuDF and RMM as the GPU execution and memory management foundation instead of writing their own CUDA kernels. NVIDIA GQE is the open-source reference architecture — demonstrating a 7.5x aggregate speedup over state-of-the-art CPU databases on TPC-H SF1000 with per-query gains up to 25.5x. Four production engines — Velox, Presto C++, SiriusDB, and cudf-polars — have already shipped on cuDF with publicly benchmarked results across TPC-H, ClickBench, and PDS. Arrow interop, spill handling, and the core columnar operator set come out of the box.