Pith. sign in

REVIEW 2 major objections 7 minor 52 references

Portable GPU engine closes gap to LLM-synthesized code to 1.27x

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · glm-5.2

2026-07-09 04:22 UTC pith:MJ6D4AWR

load-bearing objection Solid empirical contribution with a generalization gap the authors acknowledge but the conclusion overstates the 2 major comments →

arxiv 2607.07632 v1 pith:MJ6D4AWR submitted 2026-07-08 cs.DB

From Custom-Fit to Portable: Bridging the Gap Between Synthesized and Engineered GPU Query Execution

Ivan Donchev Kabadzhov , Eugenio Marinelli , Raja Appuswamy This is my paper
classification cs.DB
keywords synthesizedcodeengineperformancequeryanswerengineeredquestion
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper asks whether the 'synthesize, don't engineer' thesis for database query execution carries over from CPUs to GPUs. On CPUs, LLM-generated query-specific code has been shown to outperform general-purpose engines by 10x or more, because the abstraction overhead of a general engine is large. The authors test whether the same holds on GPUs by building SHADB, a framework that uses an LLM with a profile-guided optimization loop to synthesize query-specific CUDA or HIP kernels. They find that synthesized GPU code does outperform engineered engines substantially (7.4x over HeavyDB), approaching the memory-bandwidth ceiling. However, they then decompose the performance gap and classify the synthesized code's optimizations as either generalizable (kernel fusion, register-resident inter-operator dataflow, direct-mapped dimension tables, asymmetric batching) or workload-specific (byte-packed L2-resident maps, shared-memory privatized group-by). By lifting the generalizable optimizations into SYCLDB, a portable engine written in the SYCL programming model, they close the gap to within 1.27x of the synthesized ceiling while retaining a single codebase that runs across NVIDIA and AMD GPUs. The central claim is that on GPUs, unlike CPUs, the dominant cost is memory bandwidth rather than interpretation overhead, so once a portable engine saturates bandwidth through fusion and lifted optimizations, the residual benefit of synthesis is too small to justify its dollar cost (~$126 per benchmark suite), lack of portability, and lack of generality.

Core claim

The paper discovers that the synthesize-versus-engineer tradeoff is architecturally dependent: it does not transfer from CPU to GPU. On CPUs, general-purpose engines carry enough interpretation overhead that query-specific LLM-synthesized code can deliver an order-of-magnitude speedup. On GPUs, the bottleneck shifts to memory bandwidth, and a portable engine that achieves fusion (via SYCL dynamic functions enabling composition-based fusion without a custom IR emitter), register-resident inter-operator dataflow, and direct-mapped dimension probes can saturate that bandwidth, leaving only a 1.27x residual gap to fully specialized code. The paper also reports a negative result about tiling: the

What carries the argument

SHADB (LLM-driven synthesis framework with profile-guided optimization loop), SYCLDB (portable GPU database engine in SYCL), composition-based fusion via AdaptiveCpp dynamic functions, register table optimization, direct-mapped dimension tables, asymmetric batching by terminal type

Load-bearing premise

The conclusion that engineering beats synthesis on GPUs rests on the representativeness of the Star Schema Benchmark, which has dense primary keys and a star-schema topology that the paper's lifted optimizations directly exploit. The paper itself notes this is the only benchmark supported by one of its baselines. If the workload included more complex query topologies or non-dense keys, the generalizable optimizations might not transfer and the residual gap to synthesized code

What would settle it

If a GPU workload with sparse primary keys, complex join topologies, or non-star schemas were tested and the portable engine's gap to synthesized code widened substantially beyond 1.27x while the synthesized code maintained its advantage, the central conclusion that engineering suffices on GPUs would be weakened.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • GPU database engine design should prioritize fusion and bandwidth saturation over query-specific code synthesis, since the residual performance edge of synthesis is small, non-portable, and expensive.
  • LLMs serve better as optimization discovery tools than as runtime code generators for GPU query processing: their synthesized kernels reveal generalizable techniques that can be lifted into a portable engine.
  • Composition-based fusion via SYCL dynamic functions offers a path to fused GPU kernels without maintaining a full LLVM-based IR code generator, improving portability across GPU vendors.
  • The tile-based execution model, used by hand-written GPU database kernels, provides no benefit on bandwidth-bound scans and is a net penalty on joins compared to direct non-tiled kernels with early predicate filtering.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The conclusion is measured only on the Star Schema Benchmark, which has dense primary keys and a star topology. On workloads with sparse keys, complex multi-way joins, subqueries, or non-star topologies (e.g., TPC-H), the lifted optimizations like direct-mapped dimension tables may not apply, and the residual gap could widen.
  • The 1.27x gap could shrink further if the workload-specific optimizations the authors left out (byte-packed L2-resident maps, shared-memory privatized group-by) were implemented as conditional code paths in the portable engine, though at the cost of increased software complexity.
  • The per-row dispatch overhead of dynamic functions, which dominates on highly-selective queries that move little data, might be reduced by future SYCL compiler improvements or by a hybrid approach that falls back to static compilation for low-data-movement query shapes.
  • If future LLMs can generate portable code rather than device-specific code, or if synthesis costs drop dramatically, the cost-benefit tradeoff between synthesis and engineering could shift, though the fundamental bandwidth-ceiling argument would still constrain the achievable speedup.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

2 major / 7 minor

Summary. This paper investigates whether the 'synthesize, not engineer' thesis for query processing—previously demonstrated on CPUs—carries over to GPUs. The authors present SHADB, an LLM-driven synthesis framework with a profile-guided optimization (PGO) loop that generates query-specific CUDA/HIP kernels. On the Star Schema Benchmark (SSB), SHADB-Opt approaches the memory-bandwidth ceiling and outperforms HeavyDB, Crystal, and DuckDB. The paper then decomposes the performance gap between synthesized and engineered code, classifying optimizations as generalizable or workload-specific. Generalizable optimizations (kernel fusion via SYCL dynamic functions, direct-mapped dimension tables, asymmetric batching) are lifted into SYCLDB, a portable SYCL-based engine. The resulting SYCLDB-Opt comes within 1.27x of SHADB-Opt on SSB SF100 while retaining cross-vendor portability (NVIDIA L40S and AMD MI210). The authors conclude that on GPUs, engineering—not synthesis—remains the preferred approach, with LLMs serving as optimization-discovery tools.

Significance. The paper makes a timely and well-structured contribution to the synthesize-versus-engineer debate, extending it to GPUs for the first time. Key strengths include: (1) a concrete, reproducible PGO loop for LLM-synthesized GPU kernels with correctness verification against a DuckDB oracle; (2) a rigorous root-cause analysis that isolates generalizable from workload-specific optimizations using hardware counters (NCU, rocprof); (3) a novel composition-based fusion mechanism via AdaptiveCpp dynamic functions that avoids the need for a full IR emitter while retaining portability; (4) an ablation study (Figure 5) cleanly isolating each optimization's contribution; and (5) cross-architecture validation on both NVIDIA and AMD GPUs from a single SYCL codebase. The finding that a portable engineered engine can approach synthesized code within 1.27x is a substantive, falsifiable result that challenges the CPU-centric synthesis narrative.

major comments (2)
  1. §7 (Conclusion): The general claim that 'engineering and not synthesis remains the right vehicle for high-performance GPU query processing' is supported only by SSB results, yet §1 properly scopes the claim to 'star-schema workloads we consider in this work.' The §7 conclusion drops this qualifier. Two lifted optimizations explicitly depend on SSB's dense primary keys (§4.3.1: 'This optimization relies on the assumption that primary keys are dense enough to index directly, which is the case in SSB'), and two unlifted optimizations (byte-packed L2-resident maps, shared-memory privatized group-by; §4.3.2) are tied to SSB's specific cardinalities. On workloads with non-dense keys, snowflake schemas, or high-cardinality group-bys (e.g., TPC-H), the residual gap could widen and the generalizability of lifted optimizations may not hold. The paper should either (a) add TPC-H or another non-star
  2. §7 (Conclusion, continued): schema benchmark as a secondary evaluation, or (b) explicitly scope the §7 conclusion to star-schema workloads, matching §1. As it stands, the evidence supports only the scoped version of the claim. This is load-bearing because the paper's central thesis is the engineering-over-synthesis conclusion.
minor comments (7)
  1. Table 1: The SHADB-Base total (69.81ms) covers only 11 of 13 queries, while SHADB-Opt total (77.94ms) covers all 13. The footnote explains this, but the table layout makes direct comparison confusing. Consider visually separating the two or adding a separate row for the 11-query SHADB-Opt total (60.47ms).
  2. §2.2: 'Claude Opus 4.8' is referenced as the LLM model. As of the paper's date, this model version does not appear to exist. Please verify and correct the model name/version.
  3. §5.3: The AMD MI210 results report SYCLDB-Opt at 181.78ms vs SHADB-Opt at 150.8ms (1.2x), but the IPT parameter was changed from 4 to 16. This is a manual per-device tuning step that slightly undercuts the 'single portable binary' claim. The paper should acknowledge this as a configuration parameter or explain whether auto-tuning could determine it.
  4. §4.2.2, Listing 3: The JitCtx ABI is described textually but a formal type definition would improve reproducibility. Consider adding the struct definition.
  5. §3.2, Table 2: The microbenchmark comparing tile vs. direct kernels uses only Q1.1 and Q3.1. Adding one more join query (e.g., a selective Q3.3 or Q3.4) would strengthen the claim that tiling is a net penalty across selectivity levels.
  6. §5.2: The SF200 results are mentioned but only total times are given. Per-query breakdown or a table would help verify the 'near-linear scaling' claim.
  7. §4.3.1: The asymmetric batching heuristic (IPT=4 for scan terminal, IPT=1 for join terminal) is described as encoding 'the query shape.' It would help to clarify whether this is determined at plan time or requires runtime inspection.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the careful reading and the constructive recommendation. The referee raises a single major point concerning the scoping of our central conclusion in §7. We agree with the substance of this comment and will revise accordingly.

read point-by-point responses

  1. Referee: §7 (Conclusion): The general claim that 'engineering and not synthesis remains the right vehicle for high-performance GPU query processing' is supported only by SSB results, yet §1 properly scopes the claim to 'star-schema workloads we consider in this work.' The §7 conclusion drops this qualifier. Two lifted optimizations explicitly depend on SSB's dense primary keys (§4.3.1), and two unlifted optimizations (byte-packed L2-resident maps, shared-memory privatized group-by; §4.3.2) are tied to SSB's specific cardinalities. On workloads with non-dense keys, snowflake schemas, or high-cardinality group-bys (e.g., TPC-H), the residual gap could widen and the generalizability of lifted optimizations may not hold. The paper should either (a) add TPC-H or another non-star-schema benchmark as a secondary evaluation, or (b) explicitly scope the §7 conclusion to star-schema workloads, matching §1.

    Authors: We agree with this comment. The referee is correct that §1 carefully scopes our central claim to 'the star-schema workloads we consider in this work,' while §7 drops this qualifier and presents the engineering-over-synthesis conclusion in more general terms. This is an inconsistency we will fix in the revision. We will adopt option (b): explicitly re-scoping the §7 conclusion to star-schema workloads, matching the language already present in §1. We will also add a brief discussion in §7 acknowledging, as the referee notes, that the two lifted optimizations (direct-mapped dimension tables, asymmetric batching) and the two unlifted optimizations (byte-packed L2-resident maps, shared-memory privatized group-by) are tied to properties of star-schema workloads—dense primary keys, low-cardinality group-bys, and dimension tables that fit in L2—and that on workloads with non-dense keys, snowflake schemas, or high-cardinality group-bys (e.g., TPC-H), the residual gap could widen and the generalizability of the lifted optimizations may not hold. We believe option (b) is the appropriate choice rather than option (a) for two reasons. First, the paper's contribution is the synthesize-versus-engineer decomposition methodology and the finding that a portable engine can approach synthesized code on GPU; the SSB evaluation is sufficient to establish this for the star-schema setting, which is the standard benchmark in GPU database literature (as noted in §2.2, it is the only benchmark supported by Crystal, our hand-specialized baseline). Second, adding TPC-H would require engineering new query shapes into SYCLDB's fusion pipeline and re-running the full SHADB synthesis loop, which is beyond what a minor revision can accommodate. We will, however, add an explicit limitations paragraph in§ revision: no

Circularity Check

0 steps flagged

No significant circularity; the derivation is experimental and self-contained, with one minor self-citation of the baseline engine.

full rationale

The paper's derivation chain is: (1) SHADB synthesizes GPU kernels via an LLM+PGO loop, establishing a performance ceiling measured against external baselines (HeavyDB, Crystal, DuckDB); (2) root-cause analysis decomposes the gap between synthesized and engineered code into generalizable vs. workload-specific optimizations; (3) generalizable optimizations are lifted into SYCLDB; (4) the resulting SYCLDB-Opt is measured against the SHADB ceiling (1.27x gap). None of these steps reduce to their inputs by construction. The SHADB ceiling is independently generated and validated against external systems. The optimizations lifted into SYCLDB (fusion, register table, packed probe, asymmetric batching) are identified through profiling and analysis of SHADB's code, then independently reimplemented in a different paradigm (SYCL composition-based fusion vs. LLM-generated CUDA). The 1.27x gap is a measured result, not a fitted parameter renamed as prediction. The only self-citation is SYCLDB [20] (same authors), used as the baseline engine to optimize — this is standard systems practice (building on your prior system) and is not load-bearing for the central claim, which rests on the experimental comparison against SHADB and external baselines. No uniqueness theorem, no ansatz smuggling, no definitional circularity. Score 1 reflects the minor self-citation that is non-load-bearing.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 2 invented entities

The paper's free parameters are engineering heuristics (batch sizes, grid cap) rather than fitted scientific constants. The domain assumptions (SSB representativeness, dense keys, warm-run metric) are the main load-bearing premises. No invented theoretical entities are introduced; SHADB and the fusion technique are implemented systems with measurable performance.

free parameters (4)
  • PGO iteration budget = unspecified (convergence-based)
    The profile-guided optimization loop runs until 'a fixed iteration budget is exhausted or no further gain is found.' The budget value is not stated.
  • GRID_CAP = 262144
    Stated as a 'safe machine constraint' for the persistent-thread grid size. Chosen by hand for the L40S.
  • Items-per-thread (IPT) batch size = 4 (NVIDIA), 16 (AMD)
    Chosen per-terminal-type and per-GPU. The scan-terminal value of 4 on NVIDIA and 16 on AMD is selected to saturate bandwidth, not derived from first principles.
  • Asymmetric batching threshold = batch=4 for scan terminal, batch=1 for join terminal
    A heuristic based on terminal type. The paper states this factor 'governs the entire fused loop.'
axioms (4)
  • domain assumption SSB is representative of analytical GPU workloads
    The paper states: 'We only use SSB in this work because it is a well-established benchmark... and is the only benchmark supported by Crystal.' The conclusion that engineering beats synthesis on GPUs depends on SSB being representative.
  • domain assumption Dense primary keys are available for direct-mapped dimension tables
    The packed probe optimization 'relies on the assumption that primary keys are dense enough to index directly, which is the case in SSB' (§4.3.1). This may not hold for all schemas.
  • domain assumption Warm kernel execution time is the relevant performance metric
    The paper reports warm GPU kernel times, excluding JIT compilation and data loading. This is stated as isolating 'pure processing performance' (§2.2) but may understate real-world latency for cold or first-time queries.
  • domain assumption LLM non-determinism does not affect conclusions
    SHADB uses Claude Opus 4.8 for synthesis. The paper does not report variance across multiple synthesis runs or discuss whether different LLM sessions produce different performance characteristics.
invented entities (2)
  • SHADB independent evidence
    purpose: LLM-driven synthesis framework for GPU database kernels
    SHADB is a system contribution, not a theoretical entity. Its performance is measured against external baselines (HeavyDB, Crystal, DuckDB) and its code is publicly available. Falsifiable: other groups can run it and compare.
  • Composition-based fusion via SYCL dynamic functions independent evidence
    purpose: Portable kernel fusion without custom IR emitter
    This is a technique, not a postulated entity. It is implemented in AdaptiveCpp and its performance is measured. Falsifiable: other groups can implement it and test portability claims.

pith-pipeline@v1.1.0-glm · 27301 in / 2985 out tokens · 679052 ms · 2026-07-09T04:22:22.630872+00:00 · methodology

0 comments
read the original abstract

GPUs are increasingly used for analytical query processing, but developing GPU-based database engines that achieve the peak performance of the underlying hardware requires substantial research and engineering effort. A recent line of work argues that query processing should be synthesized, not engineered. In this scenario, instead of tuning a general-purpose engine to fit a workload, a large language model (LLM) generates code specialized to one query, one dataset, and one machine, thereby achieving an order-of-magnitude improvement in performance. This thesis, however, has so far been tested only on CPUs. In this work, we revisit the synthesize-versus-engineer debate for GPU analytics by answering three questions: (i) how good is synthesized GPU code?, (ii) why is it faster than engineered engines?, and (iii) how much of its advantage can be transferred back into a single, performance-portable engine? To answer the first question, we present SHADB, an LLM-based synthesis framework that generates optimized CUDA or HIP kernels using an automated, profile-guided optimization loop. Using SHADB, we show that the synthesized code approaches the memory-bandwidth ceiling and outperforms a state-of-the-art JIT-compiled GPU database engine (HeavyDB) by 7.4$\times$ on SSB SF100. To answer the second question, we decompose this performance gap and systematically classify optimizations as generalizable or workload-specific. Finally, to answer the third question, we integrate these generalizable optimizations into SYCLDB, a performance-portable engine written entirely in the open SYCL programming model. Using optimized SYCLDB, we show that it is possible to substantially bridge the gap to synthesized code (within 1.27$\times$ total execution time) while retaining workload-level generality and hardware-level performance portability.

Figures

Figures reproduced from arXiv: 2607.07632 by Eugenio Marinelli, Ivan Donchev Kabadzhov, Raja Appuswamy.

Figure 1
Figure 1. Figure 1: SHADB’s closed-loop, PGO pipeline. an important role in SHADB for two reasons. First, committing to the physical strategy before emitting any C++ acts as a structured Chain-of-Thought planning step [40], which reduces logical bugs and improves physical-design consistency relative to prompting for a raw kernel directly. Second, the plan is a declarative mani￾fest of the model’s intended design that can be a… view at source ↗
Figure 2
Figure 2. Figure 2: SSB SF100 query execution time on NVIDIA L40S [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: SSB SF200 query execution time on NVIDIA L40S [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: SSB SF100 query execution time on AMD MI210 [PITH_FULL_IMAGE:figures/full_fig_p010_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Per-optimization decomposition of SYCLDB kernel [PITH_FULL_IMAGE:figures/full_fig_p011_5.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

52 extracted references · 52 canonical work pages · 8 internal anchors

  1. [1]

    Azim Afroozeh, Lotte Felius, and Peter Boncz. 2024. Accelerating GPU Data Processing using FastLanes Compression. InProceedings of the 20th Workshop on Data Management on New Hardware. ACM, Santiago, Chile, 1–11

    work page 2024

  2. [2]

    Felipe Aramburu et al . 2025. Theseus: A Distributed and Scalable GPU- Accelerated Query Processing Platform Optimized for Efficient Data Movement. arXiv:2508.05029 [cs.DC] https://arxiv.org/abs/2508.05029

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  3. [3]

    Yuki Asada, Victor Fu, Apurva Gandhi, Advitya Gemawat, Lihao Zhang, Dong He, Vivek Gupta, Ehi Nosakhare, Dalitso Banda, Rathijit Sen, and Matteo Interlandi

    work page

  4. [4]

    Share the Tensor Tea: How Databases can Leverage the Machine Learning Ecosystem.Proceedings of the VLDB Endowment15, 12 (2022), 3598–3601. doi:10. 14778/3554821.3554853

    work page arXiv 2022

  5. [5]

    BlazingSQL. 2025. BlazingSQL. https://github.com/BlazingDB/blazingsql. last accessed 2025

    work page 2025

  6. [6]

    Matthias Boehm, Matteo Interlandi, and Chris Jermaine. 2023. Optimizing Tensor Computations: From Applications to Compilation and Runtime Techniques. In Companion of the 2023 International Conference on Management of Data, SIG- MOD/PODS 2023. ACM, Seattle, WA, USA, 53–59. doi:10.1145/3555041.3589407

    work page doi:10.1145/3555041.3589407 2023

  7. [7]

    Nils Boeschen, Tobias Ziegler, and Carsten Binnig. 2024. GOLAP: A GPU-in-Data- Path Architecture for High-Speed OLAP.Proceedings of the ACM on Management of Data2, 6 (Dec. 2024), Article 237, 26 pages. doi:10.1145/3698812

    work page doi:10.1145/3698812 2024

  8. [8]

    Sebastian Breß. 2014. The Design and Implementation of CoGaDB: A Column- oriented GPU-accelerated DBMS.Datenbank-Spektrum14 (2014), 199–209

    work page 2014

  9. [9]

    Jiashen Cao, Rathijit Sen, Matteo Interlandi, Joy Arulraj, and Hyesoon Kim. 2023. GPU Database Systems Characterization and Optimization.Proceedings of the VLDB Endowment17, 3 (2023), 441–454. doi:10.14778/3632093.3632107

    work page doi:10.14778/3632093.3632107 2023

  10. [10]

    Wentao Chen, Jiace Zhu, Qi Fan, Yehan Ma, and An Zou. 2025. CUDA-LLM: LLMs Can Write Efficient CUDA Kernels. arXiv preprint arXiv:2506.09092

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  11. [11]

    Periklis Chrysogelos, Manos Karpathiotakis, Raja Appuswamy, and Anastasia Ailamaki. 2019. HetExchange: Encapsulating Heterogeneous CPU-GPU Paral- lelism in JIT Compiled Engines.Proceedings of the VLDB Endowment12, 5 (2019), 544–556. doi:10.14778/3303753.3303760

    work page doi:10.14778/3303753.3303760 2019

  12. [12]

    Periklis Chrysogelos, Panagiotis Sioulas, and Anastasia Ailamaki. 2019. Hardware-conscious query processing in GPU-accelerated analytical engines. Memory1 (2019), L2

    work page 2019

  13. [13]

    Wei Cui, Qianxi Zhang, Spyros Blanas, Jesús Camacho-Rodríguez, Brandon Haynes, Yinan Li, Peng Cheng, Ravishankar Ramamurthy, Rathijit Sen, and Matteo Interlandi. 2023. Query Processing on Gaming Consoles. InProceedings of the 19th International Workshop on Data Management on New Hardware, DaMoN

    work page 2023

  14. [14]

    doi:10.1145/3592980.3595313

    ACM, Seattle, WA, USA, 86–88. doi:10.1145/3592980.3595313

    work page doi:10.1145/3592980.3595313

  15. [15]

    Mehmet Hamza Erol, Xiangpeng Hao, Federico Bianchi, Ciro Greco, Jacopo Tagliabue, and James Zou. 2026. Test-Time Optimization of Physical Query Plans with LLMs. arXiv:2602.10387 [cs.DB] https://arxiv.org/abs/2602.10387

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  16. [16]

    Govindaraju, Qiong Luo, and Pedro V

    Bingsheng He, Mian Lu, Ke Yang, Rui Fang, Naga K. Govindaraju, Qiong Luo, and Pedro V. Sander. 2009. Relational query coprocessing on graphics processors. ACM Transactions on Database Systems (TODS)34, 4 (Dec. 2009), Article 21, 39 pages. doi:10.1145/1620585.1620585

    work page doi:10.1145/1620585.1620585 2009

  17. [17]

    Nakandala, Dalitso Banda, Rathijit Sen, Karla Saur, Kwanghyun Park, Carlo Curino, Jesús Camacho-Rodríguez, Konstantinos Karana- sos, and Matteo Interlandi

    Dong He, Supun C. Nakandala, Dalitso Banda, Rathijit Sen, Karla Saur, Kwanghyun Park, Carlo Curino, Jesús Camacho-Rodríguez, Konstantinos Karana- sos, and Matteo Interlandi. 2022. Query Processing on Tensor Computa- tion Runtimes.Proceedings of the VLDB Endowment15, 11 (2022), 2811–2825. doi:10.14778/3551793.3551833

    work page doi:10.14778/3551793.3551833 2022

  18. [18]

    HEAVY.AI. 2025. HeavyDB. Archived at https://web.archive.org/web/ 20250108153216/https://www.heavy.ai/. https://www.heavy.ai/

    work page 2025

  19. [19]

    Max Heimel, Michael Saecker, Holger Pirk, Stefan Manegold, and Volker Markl

    work page

  20. [20]

    VLDB Endow6, 9 (2013), 709–720

    Hardware-oblivious parallelism for in-memory column-stores.Proc. VLDB Endow6, 9 (2013), 709–720. doi:10.14778/2536360.2536370

    work page doi:10.14778/2536360.2536370 2013

  21. [21]

    Zezhou Huang, Krystian Sakowski, Hans Lehnert, Wei Cui, Carlo Curino, Matteo Interlandi, Marius Dumitru, and Rathijit Sen. 2026. GPU Acceleration of SQL Analytics on Compressed Data.Proceedings of the VLDB Endowment19, 3 (2026), 320–333. doi:10.14778/3778092.3778095

    work page doi:10.14778/3778092.3778095 2026

  22. [22]

    Matteo Interlandi, Nicolas Bruno, Brandon Haynes, Carlo Curino, Rathijit Sen, Yinan Li, Kaushik Rajan, Bailu Ding, Lukas M. Maas, Wei Cui, Kevin Gaffney, Mingsheng Hong, Brian Kroth, Sampath Rajenda, Peng Cheng, Surajit Chaud- huri, Johannes Gehrke, Raghu Ramakrishnan, Lidong Zhou, Momin Al-Ghosien, Craig Peeper, Marius Dumitru, Conor Cunningham, Kevin Bo...

    work page doi:10.1145/3788853.3803077 2026

  23. [23]

    Ivan Donchev Kabadzhov, José Morgado, Aleksandar Ilic, and Raja Appuswamy

    work page

  24. [24]

    InProceedings of the 23rd International Workshop on Algorithms, Models and Tools for Parallel Computing on Heterogeneous Platforms (HeteroPar)

    Open, Cross-Architecture Acceleration of Data Analytics with SYCL and RISC-V. InProceedings of the 23rd International Workshop on Algorithms, Models and Tools for Parallel Computing on Heterogeneous Platforms (HeteroPar). Springer, Dresden, Germany, 1–12. https://hal.science/hal-05507632v1

    work page

  25. [25]

    Marko Kabić, Shriram Chandran, and Gustavo Alonso. 2025. Maximus: A Mod- ular Accelerated Query Engine for Data Analytics on Heterogeneous Systems. Proceedings of the ACM on Management of Data3, 3 (June 2025), Article 187, 25 pages. doi:10.1145/3725324

    work page doi:10.1145/3725324 2025

  26. [26]

    Kinetica. 2025. The Fastest Database For AI and Analytics On Real-Time Data. https://www.kinetica.com/. last accessed 2025

    work page 2025

  27. [27]

    Dimitrios Koutsoukos, Supun Nakandala, Konstantinos Karanasos, Karla Saur, Gustavo Alonso, and Matteo Interlandi. 2021. Tensors: An Abstraction for General Data Processing.Proceedings of the VLDB Endowment14, 10 (2021), 1797–1804. doi:10.14778/3467861.3467869

    work page doi:10.14778/3467861.3467869 2021

  28. [28]

    Jiale Lao and Immanuel Trummer. 2026. GenDB: The Next Generation of Query Processing — Synthesized, Not Engineered.Proceedings of the VLDB Endowment 19, 1 (2026), 1–14

    work page 2026

  29. [29]

    Jing Li, Hung-Wei Tseng, Chunbin Lin, Yannis Papakonstantinou, and Steven Swanson. 2016. Hippogriffdb: Balancing I/O and GPU bandwidth in big data analytics.Proceedings of the VLDB Endowment9, 14 (2016), 1647–1658

    work page 2016

  30. [30]

    Maas, Momin Al-Ghosien, Spyros Blanas, Nicolas Bruno, Carlo Curino, Matteo Interlandi, Craig Peeper, Kaushik Rajan, Surajit Chaudhuri, and Johannes Gehrke

    Yinan Li, Bailu Ding, Ziyun Wei, Lukas M. Maas, Momin Al-Ghosien, Spyros Blanas, Nicolas Bruno, Carlo Curino, Matteo Interlandi, Craig Peeper, Kaushik Rajan, Surajit Chaudhuri, and Johannes Gehrke. 2025. Scaling GPU-Accelerated Databases Beyond GPU Memory Size.Proc. VLDB Endow.18, 11 (July 2025), 4518–4531. doi:10.14778/3749646.3749710

    work page doi:10.14778/3749646.3749710 2025

  31. [31]

    The Time is Here for Just-in-Time Systems: Challenges and Opportunities

    Shu Liu, Alexander Krentsel, Shubham Agarwal, Mert Cemri, Ziming Mao, Soujanya Ponnapalli, Alexandros G. Dimakis, Sylvia Ratnasamy, Matei Za- haria, Aditya Parameswaran, and Ion Stoica. 2026. The Time is Here for Just-in-Time Systems: Challenges and Opportunities. arXiv:2605.24096 [cs.DB] https://arxiv.org/abs/2605.24096

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  32. [32]

    Hubert Mohr-Daurat, Xuan Sun, and Holger Pirk. 2025. BOSS - An Architecture for Database Kernel Composition.SIGMOD Rec.54, 1 (April 2025), 37–46. doi:10. 1145/3733620.3733629

    work page arXiv 2025

  33. [33]

    Thomas Neumann. 2011. Efficiently compiling efficient query plans for modern hardware.Proceedings of the VLDB Endowment4, 9 (2011), 539–550

    work page 2011

  34. [34]

    Patrick O’Neil, Elizabeth O’Neil, Xuedong Chen, and Stephen Revilak. 2009. The Star Schema Benchmark and Augmented Fact Table Indexing. InTechnology Conference on Performance Evaluation and Benchmarking (TPCTC). Springer, Berlin, Heidelberg, 237–252

    work page 2009

  35. [35]

    KernelBench: Can LLMs Write Efficient GPU Kernels?

    Anne Ouyang, Simon Guo, Simran Arora, Alex L. Zhang, William Hu, Christo- pher Ré, and Azalia Mirhoseini. 2025. KernelBench: Can LLMs Write Efficient GPU Kernels? arXiv:2502.10517 [cs.LG] https://arxiv.org/abs/2502.10517

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  36. [36]

    Nicole Hemsoth Prickett. 2016. Baidu Takes FPGA Approach to Accelerating SQL at Scale. https://www.nextplatform.com/2016/08/24/baidu-takes-fpga-approach- accelerating-big-sql/. Online

    work page 2016

  37. [37]

    Mark Raasveldt and Hannes Mühleisen. 2019. DuckDB: an Embeddable Analytical Database. InProceedings of the 2019 International Conference on Management of Data (SIGMOD). ACM, New York, NY, USA, 1981–1984. doi:10.1145/3299869. 3320212

    work page doi:10.1145/3299869 2019

  38. [38]

    RAPIDS. 2025. cuDF: A GPU DataFrame Library. https://github.com/rapidsai/ cudf. last accessed 2025

    work page 2025

  39. [39]

    Ruyman Reyes, Gordon Brown, Rod Burns, and Michael Wong. 2020. SYCL 2020: More than meets the eye. InProceedings of the International Workshop on OpenCL (IWOCL ’20). ACM, New York, NY, USA, 1–2. doi:10.1145/3388333.3388870

    work page doi:10.1145/3388333.3388870 2020

  40. [40]

    Viktor Rosenfeld, Sebastian Breß, and Volker Markl. 2022. Query Processing on Heterogeneous CPU/GPU Systems.ACM Computing Surveys (CSUR)55, 1 (Jan. 2022), Article 11, 38 pages. doi:10.1145/3485126

    work page doi:10.1145/3485126 2022

  41. [41]

    Lucas Saxena, Jan van Renen, Gaurav Saxena, Wolfgang Lehner, and Adrian Vogelsgesang. 2024. Why TPC Is Not Enough: An Analysis of the Amazon Redshift Fleet.Proceedings of the VLDB Endowment17, 11 (2024), 3694–3706. doi:10.14778/3681984.3682050

    work page doi:10.14778/3681984.3682050 2024

  42. [42]

    Anil Shanbhag, Samuel Madden, and Xiangyao Yu. 2020. A Study of the Funda- mental Performance Characteristics of GPUs and CPUs for Database Analytics. InProceedings of the 2020 ACM SIGMOD International Conference on Management of Data. ACM, New York, NY, USA, 1617–1632. doi:10.1145/3318464.3380595

    work page doi:10.1145/3318464.3380595 2020

  43. [43]

    Rank aggregation with proportionate fairness

    Anil Shanbhag, Bobbi W. Yogatama, Xiangyao Yu, and Samuel Madden. 2022. Tile-based Lightweight Integer Compression in GPU. InProceedings of the 2022 International Conference on Management of Data (SIGMOD ’22). Association for Computing Machinery, New York, NY, USA, 1390–1403. doi:10.1145/3514221. 3526132

    work page doi:10.1145/3514221 2022

  44. [44]

    Kaya Stechly, Karthik Valmeekam, and Subbarao Kambhampati. 2025. Chain of Thoughtlessness? An Analysis of CoT in Planning. arXiv:2405.04776 [cs.AI] https://arxiv.org/abs/2405.04776

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  45. [45]

    Kaibo Wang, Kai Zhang, Yuan Yuan, Siyuan Ma, Rubao Lee, Xiaoning Ding, and Xiaodong Zhang. 2014. Concurrent analytical query processing with GPUs.Proc. VLDB Endow.7, 11 (July 2014), 1011–1022. doi:10.14778/2732967.2732976

    work page doi:10.14778/2732967.2732976 2014

  46. [46]

    Johannes Wehrstein, Timo Eckmann, Matthias Jasny, and Carsten Binnig. 2026. Bespoke OLAP: Synthesizing Workload-Specific One-size-fits-one Database En- gines. arXiv:2603.02001 [cs.DB] https://arxiv.org/abs/2603.02001

    work page internal anchor Pith review arXiv 2026

  47. [47]

    Bowen Wu, Wei Cui, Carlo Curino, Matteo Interlandi, and Rathijit Sen. 2025. Terabyte-Scale Analytics in the Blink of an Eye.Proceedings of the VLDB Endow- ment19, 2 (2025), 141–155. doi:10.14778/3773749.3773754

    work page doi:10.14778/3773749.3773754 2025

  48. [48]

    Bobbi Yogatama, Weiwei Gong, and Xiangyao Yu. 2024. Scaling your Hybrid CPU-GPU DBMS to Multiple GPUs.Proceedings of the VLDB Endowment17, 13 (2024), 4709–4722. doi:10.14778/3704965.3704977

    work page doi:10.14778/3704965.3704977 2024

  49. [49]

    Bobbi Yogatama, Yifei Yang, Kevin Kristensen, Devesh Sarda, Abigale Kim, Adrian Cockcroft, Yu Teng, Joshua Patterson, Gregory Kimball, Wes McKinney, Weiwei Gong, and Xiangyao Yu. 2026. Rethinking Analytical Processing in the GPU Era. In14th Conference on Innovative Data Systems Research (CIDR ’26). CIDR, Chaminade, USA, 1–12

    work page 2026

  50. [50]

    Yogatama, Weiwei Gong, and Xiangyao Yu

    Bobbi W. Yogatama, Weiwei Gong, and Xiangyao Yu. 2022. Orchestrating Data Placement and Query Execution in Heterogeneous CPU-GPU DBMS.Proceedings of the VLDB Endowment15, 11 (2022), 2491–2503. doi:10.14778/3551793.3551809

    work page doi:10.14778/3551793.3551809 2022

  51. [51]

    Tailwind: A Practical Framework for Query Accelerators

    Geoffrey X. Yu, Ryan Marcus, and Tim Kraska. 2026. Tailwind: A Practical Framework for Query Accelerators. arXiv:2604.28079 [cs.DB] https://arxiv.org/ abs/2604.28079

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  52. [52]

    Yuan Yuan, Rubao Lee, and Xiaodong Zhang. 2013. The Yin and Yang of pro- cessing data warehousing queries on GPU devices.Proceedings of the VLDB Endowment6, 10 (2013), 817–828. 13

    work page 2013