[HN Gopher] Sirius DB
       ___________________________________________________________________
        
       Sirius DB
        
       Author : manoji
       Score  : 78 points
       Date   : 2025-12-31 05:54 UTC (3 days ago)
        
 (HTM) web link (www.sirius-db.com)
 (TXT) w3m dump (www.sirius-db.com)
        
       | stogot wrote:
       | Sounds amazing; what are the downsides that a company needs to
       | consider? Memory bottlenecks or storage bus access?
        
         | necubi wrote:
         | 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 wrote:
           | 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 wrote:
             | 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 wrote:
       | 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 wrote:
       | Reminds me of Uber's AresDB: https://www.uber.com/blog/aresdb/
        
       | tobefranklin wrote:
       | There is also a recent blog post about this:
       | https://developer.nvidia.com/blog/nvidia-gpu-accelerated-sir...
        
       | sys13 wrote:
       | I wonder if the benefit is primarily for transactional vs
       | analytical queries
        
       | manoji wrote:
       | Its sitting at the top in clickbench .Pretty cool
       | https://benchmark.clickhouse.com/#system=-&type=-&machine=-c...
        
         | riku_iki wrote:
         | improvement over DuckDb is kinda marginal (44%)
        
         | SchwKatze wrote:
         | Wow! Now I got interested on reading the paper, thanks
        
       | jauntywundrkind wrote:
       | 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
       | 
       | 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.
        
       ___________________________________________________________________
       (page generated 2026-01-03 23:00 UTC)