Will GPUs Accelerate Your Traditional SQL Workload? | Starburst

Will GPUs Accelerate Your Traditional SQL Workload?<br>July 3, 2026<br>Daniel Abadi<br>Computer Science Professor<br>University of Maryland, College Park

Daniel Abadi<br>Computer Science Professor<br>University of Maryland, College Park

Share

More deployment options<br>Request Enterprise trial license key →

Start for Free with Starburst Galaxy<br>Try our free trial today and see how you can improve your data performance.<br>Start Free

How Unity Catalog Enforces Fine-Grained Policies on Starburst Queries

Throughout my career, database workloads have almost exclusively been run on CPUs on traditional servers in the cloud or on premises. Although the research community has been publishing papers on running database workloads on GPUs for several decades, this work has been mostly at the fringes of the database community and used for niche applications in the industry.

Recently, however, GPU vendors such as NVIDIA have been marketing their chips specifically for use for database workloads, and several leading data processing vendors — including Starburst — have announced support for GPU environments along with significant performance improvements.

In truth, GPUs have in fact emerged as a legitimate tool for accelerating certain types of SQL processing. However, the expected performance improvement is very much dependent on the specifics of the SQL queries and the datasets being processed. For some workloads, the gain is enormous. For other workloads, the gain is nonexistent or even negative (to the point where performance decreases when using GPUs).

This post is designed to give the reader a brief tutorial on which database workloads are good fits for GPUs. The intention is that this information can be used as a reference for deciding whether upgrading the hardware to include GPUs would be expected to yield improved SQL performance. We will start by explaining what GPUs are and what they are designed for. Once we understand how they work, it will become easier to predict what workloads they will perform well on. We will also give some advice on what a user can do to accelerate an existing GPU database deployment.

What are GPUs good at?

Early days

Historically, GPUs were designed for the computational requirements of graphics rendering use cases. The process of rendering 3D scenes—such as calculating the color and position of millions of individual pixels and vertices—requires performing the same mathematical operations (typically floating-point operations) on large datasets simultaneously. For example, transforming a 3D model into a 2D image requires applying projection matrices to every single vertex in the scene. A CPU, which is designed for complex, sequential tasks and branching logic, would have to process these vertices one by one (or in small batches), which is extremely inefficient and unable to meet the high-throughput, low-latency requirements of real-time graphics.

To solve this, hardware engineers developed GPUs. Instead of a few powerful cores with complex control logic (like a CPU), GPUs were built with thousands of smaller, simpler cores designed to execute the same instruction on different pieces of data simultaneously (SIMD – Single Instruction, Multiple Data). Early GPUs were often "fixed-function," meaning their pipelines were hardwired specifically to perform graphics math (like rasterization and texture mapping). This specialization allowed them to achieve orders of magnitude higher throughput for these specific tasks compared to general-purpose CPUs.

In other words, in the early days of GPUs, they were almost entirely unusable for SQL workloads. They were wired specifically to perform mathematical functions relevant for an entirely different use case. Although there were some efforts to perform some database operations (especially spatial operators) via the rasterization capabilities of the hardware via languages such as OpenGL, the code was complex and limited to narrow sets of SQL operators.

Turn of the century

Everything started to change with Ian Buck’s PhD thesis work on Brook in 2004 and the subsequent release of CUDA from NVIDIA in 2007. All of a sudden, it became possible to program GPUs for general-purpose tasks. This advancement opened the door to a new era of high-performance computing, where developers could offload compute-intensive and highly parallelizable tasks—such as complex scientific simulations, financial modeling, and eventually, the training of large-scale machine learning models—to the GPU. By leveraging the thousands of small, specialized cores, programmers could solve massive problems in parallel that were previously bottlenecked by the sequential execution of traditional CPUs.

The exact details on what had to be changed in the hardware architecture and in the programming language to facilitate this translation to general-purpose processors is beyond the scope of this post. The final result is what is relevant...