> Sirius builds on GPU libraries such as libcudf [6], RMM [14], and NCCL [11], reusing optimized implemen- tations of core relational operators like joins, filters, aggregations, and data shuffle. Thanks to its modular design, Sirius also allows developers to easily switch the operator implementation between these GPU libraries and custom CUDA kernels.
https://arxiv.org/abs/2508.04701
I wonder if the various other CUDA translation layers (ZLUDA, SCALE, HIP) can host this?
It'd be so nice to see a little more foothold for Vulkan in this space. There's some good work in AI for Vulkan, it's becoming quite capable. But for databases & GPGPU, it doesn't seem like there are good rallying points.
I expect whatever does eventually emerge will perhaps likely be based on Substrait too! What an awesome common grounds thats emerged for data processing work.
In a typical company you'll have jobs, some scheduled, some ad-hoc, at a range of sizes. Most of them won't be cost-effective to run on a GPU instance, so you need a scheduling layer that estimates the size of the job and routes it to the appropriate hardware. But now what if the job is too big to run on your GPU machine? Now we either have to scale up our GPU cluster or retry it on our more flexible CPU cluster.
And this all assumes that your jobs can be transparently run across different executors from a correctness and performance standpoint.
There are niches where this makes sense (we run the same 100TB job every day and we need to speed it up), as well and large and sophisticated internal infra teams that can manage a heterogenous cluster + scheduling systems, but it's not mass-market.
I don’t understand why GPU saturation is relevant. If it’s 10x cheaper, it doesn’t matter if you only use 0.1% of the GPU, right?
Correctness shouldn’t be a concern if it implements SQL.
Curious for some more details, maybe there’s something I’m missing.
