CPU vs GPU SQL: How Velox and cuDF Make Presto Up to 4x Faster

We start from a bottleneck every analytics team knows: Presto was born as a distributed SQL engine for big data on CPU, and as data grows query time balloons. In the video, Roy and William from NVIDIA show how to break that ceiling with GPU. The work comes from IBM, NVIDIA and the Presto community; the goal is to add a GPU-accelerated engine on top of an existing warehouse without moving data. The promise is simple: instead of Java-based Presto, run Presto with Velox — a C++ execution layer — so the same SQL fans out on parallel hardware. Think of it as widening a single-lane road to eight lanes — same car, more lanes.

A quick grounding on Presto and Velox helps. Presto started at Facebook in 2012 as an open-source distributed SQL engine that separates storage and compute, scaling via coordinator and workers. In 2019 the community forked into PrestoDB and Trino; PrestoDB today lives under prestodb/presto and the Presto Foundation, hosted by the Linux Foundation. Classic Presto runs on Java. Velox, built by Meta, is a vectorized, columnar C++ execution library — the heart of Presto C++ / Presto Native. It sheds JVM overhead and executes the same query plan in vectors close to hardware. Paired with cuDF, that plan scatters across GPU cores. Analogy: replacing a Java orchestra with a small, fast C++ crew that steps directly onto the stage.

The GPU magic comes via NVIDIA cuDF and its newer extension cuDF-X. Part of RAPIDS (now NVIDIA CUDA-X), cuDF is a GPU DataFrame library — backed by libcudf and pylibcudf — that runs joins, aggregates, filters and sorts in parallel across thousands of CUDA cores. It mirrors the video: take a data frame, join, aggregate, compute — all accelerated on GPU. The bottleneck is moving data into GPU memory (VRAM). William's point is key: pushing a 100-row query to GPU makes no sense; transfer cost eats the gain. But on 179 million rows, grouped and sorted in bulk, parallelism wins clearly. 2026 GB200 NVL72 and DGX B200 runs echo the same insight — if data can move between operators without leaving GPU memory via NVLink, latency drops.

The hands-on setup in the video is three notebooks, all in the Presto Foundation's Prestorials repository. The first notebook brings up a Presto Native cluster with Docker Compose. Steps are crisp: create metastore and warehouse directories on the host, write Presto config files, then start coordinator and worker via docker compose. A verification cell shows both components Running — a CPU coordinator and a CPU worker. Then a few simple queries confirm health. This is a minimal Presto lab that operates on host data instead of building a warehouse from scratch — a one-command playground infra teams love.

The second notebook adds large data. The dataset is IBM's synthetic transactions for anti-money laundering (AML). You find it on Kaggle as "IBM Transactions for Anti Money Laundering" and also on Hugging Face; row count varies by scale, about 176 million rows at large scale. It mimics financial transactions — bank transfers, purchases, credit-card events — and is widely used for GNN and foundation-model research. The notebook loads it into the warehouse and again verifies the cluster is up with simple queries. This step sets the benchmark's realistic volume; synthetic yet prod-like in shape and scale for an analytical workload.

The third notebook delivers the new part: copy the existing warehouse and add the GPU engine on top. In Explorer you see the config and metadata duplicated verbatim, then a few extra GPU properties are added and the GPU cluster is started. Startup looks fast, but the first verification still says Starting; a second try shows Running. Then a smoke test: select star limit 1. William notes the first query takes about a second because it brings up binaries in VRAM — that warm-up cost is expected. Then a deliberate design choice: the GPU side is read-only. The reason is to avoid two writers corrupting the same files while reports and jobs still run on the CPU cluster; the GPU engine just reads. If you plan to run only the GPU engine, you can drop the restriction.

And the head-to-head. The same query — not monstrous, but grouping and sorting over all rows and returning ten rows — is sent to both engines in sequence. The code opens separate connections and cursors for CPU and GPU in a loop and times each run. The result on screen is crisp: CPU about 6 seconds, GPU 1.6 seconds. That is a 3.75× speedup, rounded to four to five times in the narration. The Docker delta is equally minimal: coordinator image prestodb/presto:latest versus gpu-nightly, worker prestodb/presto-native:latest versus gpu-nightly; a side-by-side comparison cell in Jupyter's light theme highlights the two-line difference. So copy the warehouse, flip the image tag, add a few GPU properties — the speed win is that close.

Zooming out, the picture comes together. The three notebooks in Prestorials show how to place a second, faster tier next to a production warehouse without moving data and while keeping the same SQL. The IBM + NVIDIA Velox + cuDF integration, as described in the March 2026 arXiv VLDB workshop paper, focuses on two hard problems: moving data from storage to GPU operators and keeping operator exchange inside GPU memory. Early evaluations on TPC-H-derived queries report up to 6× cost/performance gains. The video gives a concrete lab proof on 179 million rows: 6 versus 1.6 seconds. The closing is practical: if you want to try GPU-accelerated Presto, clone Prestorials, run the same notebooks, and share your own speedup in the comments.