Proteus cuts GPU query memory by 54% without paying a decompression round trip

The result

A new PVLDB evaluation puts a concrete price on compressed execution inside a compiled GPU database. Across eight queries from SSB, TPC-H and the Stack workload, Proteus with the paper’s CB2T operator and FLBP compression reduced GPU memory footprint by 54% on average versus uncompressed Proteus while adding 8% average runtime overhead. The alternative RFOR codec reduced footprint by 60%, but its average runtime penalty rose to 45%.[^1]

Those figures are not a leaderboard score for natural-language-to-SQL quality. They measure the execution layer that increasingly sits underneath analytics agents: whether generated SQL can stay resident on a shared GPU without first inflating compressed columns into expensive high-bandwidth memory.

The placement test

The paper compares four execution paths on an NVIDIA A100-SXM4 with 40 GB of HBM2. The workloads are SSB at scale factor 100, selected TPC-H queries at scale factor 100, and two Stack queries over a fixed StackExchange dump. Every reported measurement averages 10 timed runs after one warmup.[^1]

The decisive result is about placement. On scan-heavy SSB Q1.1, decompressing RFOR into a full global-memory buffer produced 20.60 GB of physical HBM traffic; FLBP produced 21.13 GB. Decoding into shared memory and consuming each tile inside the same generated kernel cut those totals to 3.2 GB and 3.9 GB, respectively—reductions of 6.3× and 5.6× against pre-decompression.[^1]

The end-to-end cases show the tradeoff more clearly. FLBP-Shared matched uncompressed Proteus on SSB Q1.1 at 19.7 ms while shrinking the footprint from 9.6 GB to 3.8 GB. On the deeper TPC-H Q5 pipeline, it used 5.46 GB instead of 11.53 GB, but took 139 ms rather than 110.5 ms. On Stack Q11, it reduced memory from 0.597 GB to 0.168 GB while essentially matching runtime: 8.97 ms versus 8.99 ms.[^1]

What the comparison does not prove

This is not a clean engine ranking. HeavyDB, Sirius and Proteus use different memory-pool policies, type lowering, SQL rewrites and physical join plans; compilation and SQL planning time are excluded. The authors explicitly frame those results as production-baseline comparisons rather than identical-plan tests.[^1]

The specialized Crystal kernels are also still 2.7×–4.7× faster than their Proteus counterparts on SSB. CB2T’s contribution is therefore not the lowest absolute latency. It is a reusable compiler boundary that preserves much of compression’s memory benefit without materializing decoded columns or rewriting every downstream operator.[^1]

That distinction matters for agentic analytics infrastructure. A system can trade a modest amount of query time for roughly half the resident memory, but the right choice remains query- and codec-dependent. The benchmark’s strongest practical recommendation is narrow: decode into shared memory by default, then tune launch geometry rather than assuming maximum occupancy gives minimum runtime.[^1]

[^1]: Boffa et al., “Tile-Based Decompression in Compiled GPU Engines,” arXiv 2610.32695 / PVLDB 20(2), submitted Oct. 23, 2026.