3 ms·

Sirius DB

144 points by manoji 9mo ago

stogot 9mo ago
Sounds amazing; what are the downsides that a company needs to consider? Memory bottlenecks or storage bus access?
- necubi 9mo ago
  One downside is that you're paying for the GPU whether you're fully using it or not. It takes big queries to saturate a GH200, and if you're only using 10% of the capacity of the GPU it doesn't really matter that it's 10x faster. 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.
  - srcreigh 9mo ago
    The website claims it’s 10x cheaper (“10x faster on same hardware costs”) and implements SQL execution. 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.
    - zX41ZdbW 9mo ago
      GPU databases can run a small subset of production workloads in a narrow combination of conditions. There are plenty of GPU databases out there: mapD/OmniSci/HeavyDB, AresDB, BlazingSQL, Kinetika, BrytlytDB, SQReam, Alenka, ... Some of them are very niche, and the others are not even usable.
adrianco 9mo ago
I’ve talked to the authors of this, it’s a very interesting project. GPU memory space used to be the limitation but the latest generations of GPUs have enormous shared memory capacity and need something like SiriusDB to manipulate and prepare data in-place before the AI algorithms get to work.
esafak 9mo ago
Reminds me of Uber's AresDB: https://www.uber.com/blog/aresdb/ https://www.uber.com/blog/aresdb/
tobefranklin 9mo ago
There is also a recent blog post about this: https://developer.nvidia.com/blog/nvidia-gpu-accelerated-sirius-achieves-record-setting-clickbench-record/ https://developer.nvidia.com/blog/nvidia-gpu-accelerated-sir...
sys13 9mo ago
I wonder if the benefit is primarily for transactional vs analytical queries
- anentropic 9mo ago
  it'll be purely for analytical queries
manoji 9mo ago
Its sitting at the top in clickbench .Pretty cool https://benchmark.clickhouse.com/#system=-&type=-&machine=-ca2l%7C6t%7Cg4e%7C6ax%7C6ale%7C3al&cluster_size=-&opensource=-&hardware=-&tuned=+n&metric=hot&queries=- https://benchmark.clickhouse.com/#system=-&type=-&machine=-c...
- riku_iki 9mo ago
  improvement over DuckDb is kinda marginal (44%)
  - thesz 9mo ago
    44% is not marginal. "Marginal" is what perceived by seller and buyer as negligible and it tops at 5%.
    - riku_iki 9mo ago
      its marginal compared to promised 10x improvement.
- SchwKatze 9mo ago
  Wow! Now I got interested on reading the paper, thanks
- canadiantim 9mo ago
  It really is a SeriousDB
jauntywundrkind 9mo ago
From their Rethinking Analytical Processing in the GPU Era paper, > 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 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.
ledbit 9mo ago
Some of the price performance improvement that is quoted is due to using $ from different cloud providers - eg a GH200 in Lambda Labs costs $1.5/hr, but the closest equivalent in AWS (p5.4xlarge) costs $6.88/hr. Which means, ~4.5x of the price performance benefits is not real ...

Sirius DB

144 points by manoji 9mo ago

stogot 9mo ago

Sounds amazing; what are the downsides that a company needs to consider? Memory bottlenecks or storage bus access?

necubi 9mo ago
One downside is that you're paying for the GPU whether you're fully using it or not. It takes big queries to saturate a GH200, and if you're only using 10% of the capacity of the GPU it doesn't really matter that it's 10x faster. 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.
- srcreigh 9mo ago
  The website claims it’s 10x cheaper (“10x faster on same hardware costs”) and implements SQL execution. 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.
  - zX41ZdbW 9mo ago
    GPU databases can run a small subset of production workloads in a narrow combination of conditions. There are plenty of GPU databases out there: mapD/OmniSci/HeavyDB, AresDB, BlazingSQL, Kinetika, BrytlytDB, SQReam, Alenka, ... Some of them are very niche, and the others are not even usable.

adrianco 9mo ago

I’ve talked to the authors of this, it’s a very interesting project. GPU memory space used to be the limitation but the latest generations of GPUs have enormous shared memory capacity and need something like SiriusDB to manipulate and prepare data in-place before the AI algorithms get to work.

esafak 9mo ago

Reminds me of Uber's AresDB: https://www.uber.com/blog/aresdb/ https://www.uber.com/blog/aresdb/

tobefranklin 9mo ago

There is also a recent blog post about this: https://developer.nvidia.com/blog/nvidia-gpu-accelerated-sirius-achieves-record-setting-clickbench-record/ https://developer.nvidia.com/blog/nvidia-gpu-accelerated-sir...

sys13 9mo ago

I wonder if the benefit is primarily for transactional vs analytical queries

anentropic 9mo ago
it'll be purely for analytical queries

manoji 9mo ago

Its sitting at the top in clickbench .Pretty cool https://benchmark.clickhouse.com/#system=-&type=-&machine=-ca2l%7C6t%7Cg4e%7C6ax%7C6ale%7C3al&cluster_size=-&opensource=-&hardware=-&tuned=+n&metric=hot&queries=- https://benchmark.clickhouse.com/#system=-&type=-&machine=-c...

riku_iki 9mo ago
improvement over DuckDb is kinda marginal (44%)
- thesz 9mo ago
  44% is not marginal. "Marginal" is what perceived by seller and buyer as negligible and it tops at 5%.
  - riku_iki 9mo ago
    its marginal compared to promised 10x improvement.
SchwKatze 9mo ago
Wow! Now I got interested on reading the paper, thanks
canadiantim 9mo ago
It really is a SeriousDB

jauntywundrkind 9mo ago

From their Rethinking Analytical Processing in the GPU Era paper, > 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 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.

ledbit 9mo ago

Some of the price performance improvement that is quoted is due to using $ from different cloud providers - eg a GH200 in Lambda Labs costs $1.5/hr, but the closest equivalent in AWS (p5.4xlarge) costs $6.88/hr. Which means, ~4.5x of the price performance benefits is not real ...