Sirius: GPU accelerated analytics that plugs into your existing database

The whole design is interception, not rewriting

Sirius is a GPU-native composable analytics engine, and the sentence that defines it is that it plugs into existing databases via the standard Substrait query format, requiring no query rewrites or major system changes. It currently supports DuckDB, with StarRocks marked as coming soon, and other systems marked with an asterisk are on the roadmap. It is built on the NVIDIA CUDA-X libraries, including cuDF, cuVS and cuCascade. The mechanism in practice is that once the extension is loaded, all DuckDB queries are automatically intercepted by the optimizer hook and run on the GPU, and the README states it plainly that no query rewrites are required and that queries with unsupported operators fall back silently to the CPU. That silent fallback is the design decision with consequences, because a query that looked like it ran on the GPU may have run on the CPU, and the only control you have is a setting. There is a session level `SET gpu_execution = false` and a database wide `SET GLOBAL gpu_execution = false`.

Out of core execution with tiered memory

The README describes the execution model as out-of-core with tiered memory management across GPU, host and disk, with automatic data partitioning and spilling, and it works with both Parquet and DuckDB-native storage. This is the part of the design that makes it an analytics engine rather than a GPU kernel library, because a GPU has a fixed amount of memory and a query that does not fit has to go somewhere. The three tiers are the answer, with data partitioned automatically and spilled when the GPU tier fills, and the detail in the repository is that the build and configuration and testing details live in a document called `gpu_execution.md`. For an evaluator, that is the file to read, because the behaviour of the engine on a dataset larger than VRAM is decided there rather than in the top level README.

Pinning tables to skip the file system entirely

There is a second performance mechanism, and it is the more interesting one for a user with a repeated query pattern. Sirius reads table data from storage on every query, so for the best hot-run performance you can pin frequently queried tables, where `pin_table` materialises a table's columns into memory once and subsequent queries over that source are served straight from the pinned copy, skipping file I/O and decode entirely. The reassuring detail is that queries do not change, because pinned tables are matched automatically, so the same SQL keeps working and the engine decides to serve it from the pinned copy.

-- Pin a parquet file (or glob) into GPU memory; omit cols to pin all columns
CALL pin_table('/path/to/lineitem.parquet', name = 'lineitem', tier = 'gpu',
               cols = ['l_orderkey', 'l_quantity', 'l_extendedprice', 'l_shipdate']);

You can pin a DuckDB base table instead, with the format and name given and no file path, and you release the memory with `unpin_table`. The tier argument is what selects where the pinned columns live, with a GPU tier pinning columns in GPU memory, and the columns list lets you pin only the ones your query touches, which is how you avoid spending scarce VRAM on a wide table when the query only touches four columns.

The requirements list is the real specification

The README's requirements section is where an evaluator should slow down, because each line is a hard gate. The operating system must be Linux on amd64 or x86_64, or arm64 or aarch64, with glibc 2.28 or newer. The GPU must be an NVIDIA Turing or newer with compute capability 7.5 or above, and the CUDA version must be 13.x with a driver of 580.65.06 or newer, or 12.x with a driver of 525.60.13 or newer. `io_uring` has to be enabled at runtime, with the kernel configuration flag and a recommendation that `kernel.io_uring_disabled=0` be set, and containers must be allowed to make the `io_uring_setup`, `io_uring_enter` and `io_uring_register` calls, which is a detail that will stop a containerised deployment dead if the runtime blocks them. And local Parquet files should sit on a filesystem or block device that supports direct I/O with `O_DIRECT`. None of these are exotic; all of them are real.

Building it, and the two release channels

The build needs Git and Pixi, and the source tree is a set of submodules, since the clone is done with `--no-recurse-submodules` and the submodules are then initialised explicitly for DuckDB, Substrait, cuCascade and the two directories under `sirius-duckdb`.

git clone --no-recurse-submodules https://github.com/sirius-db/sirius.git
cd sirius
git submodule update --init --depth=1 --jobs 5 duckdb substrait cucascade sirius-duckdb/duckdb sirius-duckdb/extension-ci-tools
pixi run make TEST_BUILD_TARGET=
pixi run duckdb

For people who do not want to compile anything, there are two prebuilt release channels with deliberately different semantics. The `stable` tag is a maintainer-selected build that is promoted manually, and the `latest` tag tracks the newest successful build on `main` automatically, where the README warns you may encounter breaking changes. Both release notes carry full install instructions, covering installing a matching DuckDB version, downloading the right binary for your platform, and a sample query to try it with. The word matching is important, because Sirius ships a DuckDB extension and the extension is compiled against a specific DuckDB revision.

The Python API comes with a version caveat

Sirius is used from DuckDB's Python API, by loading the extension, executing SQL and fetching results, with supported queries running on the GPU automatically just as in the shell. The caveat is specific and worth quoting, that the v2 extension requires the exact DuckDB revision pinned in this repository, and that the default environment's DuckDB 1.5 Python package cannot load this extension, so Python use requires a package built from the matching revision. The same constraint applies to the benchmark and power and throughput runners, which need a Python DuckDB client built from the pinned v2 revision, while the CLI based scripts use the built v2 host. The example itself enables `allow_unsigned_extensions` so that the locally built extension can be loaded, and the README says to run it with `pixi run python example.py` from the repository root.

Project shape, performance claims and governance

The performance section presents TPC-H hot runs on AWS across 22 queries, comparing the best Sirius g7e instance size against DuckDB on an m9g.16xlarge, plotted as cost per run on log scales where lower left is better, and the README notes that the legacy Sirius implementation used for the ClickBench results lives in a `legacy-dev` archive pinned at a specific commit. The repository is a C++ project with CMake presets, a Makefile whose targets cover release, debug, the clang variants including asan and tsan builds, several test variants, S3 test targets of different sizes and a slot gate test, and the release build wires sccache into the compiler launcher. The quality tooling includes clang-format, clang-tidy, a clangd configuration, a pre-commit setup, a markdown linter configuration and a thread sanitizer suppression file, and the governance documents are a `GOVERNANCE.md`, a `MAINTAINERS.md`, a code of conduct and a contribution guide, alongside agent instruction directories. The licence is Apache-2.0, the project talks on Slack, and the last push was on 2026-10-15.

Editorial conclusion

Adopt Sirius if you already run analytical DuckDB workloads, you have recent NVIDIA hardware, and you want GPU execution without a query rewrite or a fork of your database. Do not adopt it without reading the requirements, because a Turing or newer GPU with compute capability 7.5, a specific CUDA generation, `io_uring` enabled and direct I/O capable storage are all hard gates, and containers have to be allowed to make the `io_uring` syscalls. Before you plan around the Python API, note that the extension only loads against the exact DuckDB revision the repository pins, and that the default 1.5 Python package cannot load it. The licence is Apache-2.0, the stable release tag is maintained by hand while `latest` tracks main, and the last push was on 2026-10-15.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sirius-db/sirius on GitHub