Do GPUs Really Need New Tabular File Formats?

This paper demonstrates that GPU scan performance bottlenecks in Parquet files stem from suboptimal, CPU-centric configurations rather than the format itself, and shows that applying GPU-aware settings can boost effective read bandwidth to 125 GB/s without altering the Parquet specification.

The Gist

Imagine you have a massive library of books (your data) stored in a warehouse (your hard drive). You also have a super-fast robot librarian (your GPU) whose job is to read these books and answer questions.

For years, the library has been organized using a specific filing system called Parquet. This system was designed with a human librarian in mind: it groups books into small, manageable piles that a human can easily pick up one by one.

However, the robot librarian is different. It doesn't just pick up one pile at a time; it has thousands of hands and can grab dozens of piles simultaneously. But because the library is still organized for humans, the robot spends most of its time waiting for the next pile to be handed to it, or it's only using a tiny fraction of its hands. The robot is incredibly fast, but the library organization is holding it back.

The paper asks a simple question: Do we need to invent a brand-new filing system just for robots?

The authors say: No. Instead, we just need to rearrange the existing books using a few simple rules.

Here is how they fixed the problem, using four main "rules of the road":

1. The "More Piles" Rule (Increase Page Count)

• The Problem: The old system put all the data for a section into one giant, heavy book. The robot tried to read it, but it could only use one hand at a time because the book was too big to split up.
• The Fix: They chopped those giant books into many smaller, thinner pages. Now, the robot can grab 100 pages at once with its 100 hands.
• The Result: The robot is no longer waiting around; it's busy using all its hands at once.

2. The "Big Boxes" Rule (Increase Row Group Size)

• The Problem: The old system sent the robot tiny, postage-stamp-sized packages. Even though the robot is fast, the delivery truck (the connection between the drive and the robot) gets clogged with too many tiny packages.
• The Fix: They started sending huge, full-sized moving boxes instead of postage stamps.
• The Result: The delivery truck can now drive at full speed, keeping the robot constantly fed with data.

3. The "Smart Packing" Rule (Encoding Flexibility)

• The Problem: The old system packed the books using a generic, one-size-fits-all method. Sometimes this made the books smaller, but often it didn't help much.
• The Fix: They looked at each book individually and chose the best way to shrink it. If a book had lots of repeated words, they used a special code to make it tiny. If a book was already short, they left it alone.
• The Result: The books take up less space on the shelf, so the delivery truck has less weight to carry, making the whole process faster.

4. The "Don't Wrap It" Rule (No Unnecessary Compression)

• The Problem: Sometimes, the old system wrapped books in heavy bubble wrap (compression) even when the books were already small. The robot then had to spend time unwrapping them, which wasted energy.
• The Fix: They decided: "If the bubble wrap doesn't make the package significantly smaller, don't use it."
• The Result: The robot saves time by skipping the unwrapping step for books that didn't need it.

The Grand Finale: The Robot vs. The Human

The authors tested this new arrangement.

• The Old Way: The robot was slow, barely using its superpowers.
• The New Way: By just reorganizing the existing Parquet files (without inventing a new format), they made the robot 125 times faster in terms of data reading speed.

They also showed that when the robot works in sync with the delivery truck (overlapping reading and processing), it becomes even more efficient. In fact, this reorganized robot was so fast that it nearly reached the theoretical speed limit of the delivery truck itself.

The Bottom Line

The paper concludes that we don't need to burn down the library and build a new one from scratch. We just need to re-shelve the books with a few smart adjustments.

By tweaking how the data is packed and grouped, the existing Parquet format can already run at lightning speed on modern GPUs. This saves everyone the trouble of learning a new system and keeps all the old software compatible, while still getting the massive speed boost we wanted.

Technical Summary

Technical Summary: Do GPUs Really Need New Tabular File Formats?

Problem Statement

Apache Parquet is the de facto columnar file format in modern analytical systems, yet its default configuration guidelines are shaped by CPU-centric execution engines. As GPU-accelerated data processing becomes prevalent, Parquet files optimized for CPUs often severely underutilize GPU hardware, creating an artificial performance bottleneck. Despite extensive CPU-side testing, Parquet reading remains a major bottleneck in GPU-accelerated analytics; for instance, the NVIDIA RAPIDS team reports that approximately 85% of TPC-H benchmark runtime is spent on Parquet scans rather than query operators. This raises the central research question: Do GPUs truly require new tabular file formats, or can existing Parquet configurations be optimized to achieve high performance?

Methodology

The authors conducted a systematic study to evaluate how Parquet configuration choices affect GPU scan performance. The experimental setup utilized a single NVIDIA A100 GPU reading the largest TPC-H SF300 table (lineitem) from local NVMe SSDs via GPUDirect Storage (GDS). The study employed PystachIO, a GPU-accelerated analytical system that fully overlaps I/O and GPU computation, built upon the NVIDIA RAPIDS cuDF library.

The methodology involved:

1. Baseline Establishment: Generating Parquet files using DuckDB's default settings (single page per column chunk, 122,880 rows per Row Group (RG), Parquet V1 encodings, and standard compression).
2. Configuration Iteration: Systematically modifying file parameters to test four specific dimensions:
   • Page Count: Increasing the number of pages per RG to match GPU kernel grid sizes.
   • Row Group (RG) Size: Increasing the number of rows per RG to create larger I/O units suitable for GDS.
   • Encoding Flexibility: Allowing per-chunk selection of optimal encodings from both Parquet V1 and V2 schemes.
   • Compression Selectivity: Skipping compression for column chunks where the size reduction does not exceed a specific threshold (10%).
3. Tool Development: The authors developed a Parquet rewriter tool (written in Rust) to transform existing Parquet files into these optimized configurations without altering the file format specification.
4. Performance Metrics: Evaluation focused on effective read bandwidth (logical raw data size divided by scan runtime) and end-to-end query runtime for TPC-H queries (Q6 and Q12) across varying dataset scales (up to SF1000).

Key Contributions and Insights

The paper presents four primary insights derived from the experimental results:

1. Page Count Optimization: GPU decoding kernels parallelize across pages. Default configurations often result in too few pages, leaving the GPU underutilized. Increasing the page count to 100 or above significantly improves decoding efficiency and storage bus bandwidth.
2. RG Size Optimization: The GPU I/O stack (GDS) behaves differently from CPU stacks, preferring larger I/O units (MiB-scale) to saturate storage bandwidth. Default RG sizes (resulting in ~100 KB chunks) are suboptimal. Increasing RG sizes to millions of rows (e.g., 10M rows) allows GDS to saturate SSDs.
3. Encoding Flexibility: Restricting encodings to Parquet V1 limits compression efficiency. Allowing the selection of the smallest encoded size from both V1 and V2 schemes (e.g., utilizing Delta Binary Packed for integers) improves compression ratios. This reduces the I/O bottleneck and leverages efficient V2 decoding on GPUs.
4. Avoiding Unnecessary Compression: Blindly applying compression adds decompression overhead. The study shows that skipping compression when the size reduction is below a 10% threshold improves performance, particularly in scenarios where the GPU is compute-bound (e.g., when reading from multiple SSDs).

Results

By applying these GPU-aware configurations to fully compliant Parquet files, the authors achieved the following results:

• Effective Bandwidth: The optimized configuration achieved up to 125 GB/s effective read bandwidth using 4 SSDs, a dramatic improvement over the baseline.
• Scalability: The effective bandwidth scaled linearly with the number of SSDs when encoding flexibility was applied, whereas baseline configurations saturated early.
• Query Performance: On TPC-H queries (Q6 and Q12), the GPU system using optimized Parquet files significantly outperformed CPU systems (ClickHouse and DuckDB) and remained close to the theoretical minimum runtime (defined by SSD bandwidth).
• No New Format Required: The study demonstrates that high GPU performance can be achieved without switching to a new file format, preserving the interoperability benefits of the Parquet ecosystem.

Significance and Claims

The paper argues that new file formats are not strictly necessary for high-performance GPU analytics. Instead, the performance gap is largely a consequence of suboptimal configuration choices inherited from CPU-centric defaults.

• Practical Guidance: The work provides the first practical guidance on optimizing Parquet for GPU databases, enabling substantial acceleration through configuration rather than format replacement.
• Baseline for Future Work: The authors establish a strong baseline for future GPU file formats. They assert that any proposed new format must outperform these optimized Parquet configurations (which achieve ~125 GB/s) rather than merely improving over unoptimized defaults.
• Ecosystem Preservation: By maintaining compatibility with the existing Parquet specification and ecosystem, the proposed approach avoids the costs associated with migrating to proprietary or new formats.
• Hardware Agnosticism: While focused on GPUs, the rewriter tool is not hardware-specific; it applies configurations based on the target hardware's characteristics, suggesting that frequent queries on any hardware could benefit from such rewriting.

The authors conclude that while new formats targeting in-GPU-memory decoding exist, the dominant bottleneck in real-world scenarios remains storage I/O. Therefore, optimizing the existing Parquet format to maximize storage throughput and minimize decompression overhead is a critical, immediate step before considering entirely new file format designs.