{"slug": "show-hn-craton-bolt-a-pure-rust-jit-compiled-gpu-sql-engine", "title": "Show HN: Craton Bolt – A Pure Rust, JIT-Compiled GPU SQL Engine", "summary": "Craton Bolt v0.7.0, a pure Rust JIT-compiled GPU SQL engine, compiles each query into a fresh NVIDIA PTX kernel at runtime via the CUDA driver API, eliminating C++ shims and precompiled kernels. The engine supports a broad SQL surface including GROUP BY, joins, window functions, and recursive CTEs, with borrow-checked GPU memory for compile-time safety. It targets sm_70 (Volta) and newer GPUs and is in active development.", "body_md": "JIT-compiled GPU SQL engine. SQL strings go in, NVIDIA PTX comes out at runtime, the GPU does the rest.\n\nCraton Bolt is a SQL execution engine written in Rust that compiles each query into a fresh NVIDIA PTX kernel at runtime, loads it via the CUDA driver, and runs it on the GPU. There is no C++ shim, no precompiled kernel library, and no FFI to a third-party query engine. The full pipeline — parse → plan → codegen → launch — is pure Rust on top of the raw CUDA driver API.\n\nThe project's two distinguishing ideas:\n\n**Kernel fusion via runtime PTX.** Most GPU dataframe engines (RAPIDS / cuDF) chain precompiled kernels and bounce intermediates through global memory. Craton Bolt emits a single PTX kernel per query, keeping the entire fused expression tree in registers. Comparable in spirit to what Polars / DataFusion do for the CPU via codegen and Arrow-native vectorisation, but targeting the GPU.**Borrow-checked GPU memory (\"CUDA-Oxide\").** GPU allocations are typed handles (`GpuVec<T>`\n\n), borrowed as`GpuView<'a, T>`\n\nfor read-only access and`GpuViewMut<'a, T>`\n\n(a`!Sync`\n\n,`!Copy`\n\nexclusive handle) for write access. Kernel launches require those borrows, so use-after-free, double-free, and mutable / shared aliasing across kernel boundaries are rejected at compile time. The host-side type system makes the same guarantees Rust already makes for CPU memory.\n\n**Active development — v0.7.0.** The crate compiles clean on Windows MSVC and Linux against a CUDA Toolkit ≥ 12. It targets `sm_70`\n\n(Volta) and newer. End-to-end pipelines for projection, filter, scalar aggregate, GROUP BY (multi-tier shared-memory + hash-partitioned), joins (`INNER`\n\n/ `LEFT [OUTER]`\n\n/ `RIGHT [OUTER]`\n\n/ `FULL [OUTER]`\n\non GPU when the shape qualifies, host-side hash join otherwise; `CROSS`\n\non GPU or host; plus small-cardinality non-equi joins via a host nested-loop fallback), `DISTINCT`\n\n, `ORDER BY`\n\n(GPU bitonic sort integrated, plus an env-gated GPU radix path; host `lexsort`\n\nfallback), `LIMIT`\n\n, `HAVING`\n\n, `UNION [ALL]`\n\n, `EXCEPT [ALL]`\n\n, and `INTERSECT [ALL]`\n\nare implemented. The frontend also accepts CTEs (`WITH`\n\n, including `WITH RECURSIVE`\n\n— linear, non-linear, and mutual), derived tables and `LATERAL`\n\nsubqueries in `FROM`\n\n, uncorrelated subqueries plus a single correlated `WHERE`\n\nsubquery (`EXISTS`\n\n/ `NOT EXISTS`\n\n/ scalar), `VALUES`\n\nas a row source, the `generate_series`\n\ntable-valued function, `DISTINCT ON`\n\n, host-side window functions with named `WINDOW`\n\nclauses and `QUALIFY`\n\n, super-aggregates (`ROLLUP`\n\n/ `CUBE`\n\n/ `GROUPING SETS`\n\n), and query-clause sugar (`FETCH`\n\n/ `TOP`\n\n→ `LIMIT`\n\n, `FOR UPDATE`\n\nno-op, `PREWHERE`\n\n→ `WHERE`\n\n). The scalar surface includes `IN`\n\n, `BETWEEN`\n\n, `CASE`\n\n, `CAST`\n\n, `COALESCE`\n\n/ `NULLIF`\n\n, and `LIKE`\n\n(numeric/Bool results lower to GPU). `Decimal128`\n\nhas full GPU arithmetic (`+`\n\n, `-`\n\n, `*`\n\n, `/`\n\n) and comparisons, with scalar **and** grouped GPU `SUM`\n\n/ `MIN`\n\n/ `MAX`\n\n; `Date32`\n\n/ `Timestamp`\n\narithmetic (Date−Date, Timestamp−Timestamp, Day-INTERVAL) lowers to GPU. String predicates run as genuine integer GPU paths when dictionary-encoded — `=`\n\n, `!=`\n\n, `IN`\n\n, and `LIKE`\n\n\\ equality over dictionary-encoded `Utf8`\n\nfold to pure integer index-membership predicates on the GPU, and `LENGTH`\n\nlowers to the integer `StringLength`\n\nGPU path. The non-dictionary string **device** path (the `LIKE`\n\nmatcher plus the two-pass `UPPER`\n\n/ `LOWER`\n\n/ `CONCAT`\n\n/ `SUBSTRING`\n\n/ `TRIM`\n\nproducers) is **host-validated only** as of v0.7.0 and **not enabled by default**: the byte-identical host path is the default correctness path, and the device kernels are reached only behind the opt-in `BOLT_GPU_STRING`\n\nenv var (see [ docs/ENV_VARS.md](/craton-co/craton-bolt/blob/main/docs/ENV_VARS.md) /\n\n[).](/craton-co/craton-bolt/blob/main/docs/LIMITATIONS.md)\n\n`docs/LIMITATIONS.md`\n\n[is the authoritative list of the supported SQL surface. Production use is](/craton-co/craton-bolt/blob/main/docs/SQL_REFERENCE.md)\n\n`docs/SQL_REFERENCE.md`\n\n**not** recommended — the public API is unstable pre-1.0.\n\nCI runs no GPU code.The CI pipeline builds, tests, lints, and runs`cargo deny`\n\nusing the`cuda-stub`\n\nfeature only — it exercises0 GPU code pathsbecause no GPU runner exists. The`#[ignore]`\n\n-gated CUDA integration tests are dark in CI; GPU correctness is validated separately on developer/maintainer hardware (see[for the verification harness). Treat CI green as \"host logic + codegen shape are sound,\" not \"GPU execution is verified.\"]`docs/BENCHMARKS.md`\n\nLimitations / not yet production-ready.See[for the consolidated list of requirements, pre-1.0 caveats, and known semantic gaps before you depend on Craton Bolt.]`docs/LIMITATIONS.md`\n\nSee [ docs/SQL_REFERENCE.md](/craton-co/craton-bolt/blob/main/docs/SQL_REFERENCE.md) for the exact supported subset.\n\n| Layer | What it does |\n|---|---|\n`src/cuda/` |\nRaw CUDA driver FFI, Arrow-aligned device buffers, borrow-checked `GpuVec` , host-side dictionary encoders (i32 and i64 indices). |\n`src/plan/` |\nLogical plan AST, lazy `DataFrame` builder, SQL frontend (sqlparser), physical-plan lowering with SSA-shaped IR, string-literal predicate rewriting. |\n`src/jit/` |\nPTX codegen — projection kernels, predicate-only kernels, scalar reductions, GROUP BY hash kernels (sentinel-based and valid-flag), float-atomic MIN/MAX via CAS loop, single-pass and multi-pass prefix scan, gather, hash-join build/probe kernels, and bitonic + radix sort kernels. The NVRTC-equivalent driver path (`cuModuleLoadData` ) and the `KernelSpec` -keyed module cache are also here. |\n`src/exec/` |\nTop-level engine; per-shape executors (scalar / GROUP BY / pre-projection / pre+GROUP BY / wide keys / sentinel-free); GPU and host hash-join executors; GPU and host ORDER BY; GPU and host filter compaction; dictionary registry; host-side aggregate fallbacks for Bool / Utf8. |\n\n- Rust 1.74 or newer (2021 edition).\n- An NVIDIA CUDA Toolkit ≥ 12, with\n`cuda.lib`\n\n(Windows) /`libcuda.so`\n\n(Linux) on the linker path. - An NVIDIA GPU with compute capability ≥ 7.0 (Volta or newer) and a driver matching the toolkit.\n\n`cargo check`\n\nand `cargo build --lib`\n\nwork on a host without CUDA installed (everything type-checks). `cargo test`\n\nand `cargo bench`\n\nrequire the linker to find `cuda.lib`\n\n; the ignored integration tests further require an actual GPU.\n\n**Linux (x86_64):** supported.**Windows (x86_64 MSVC):** supported.**macOS (any arch):** NOT supported — Apple ended CUDA support in 2019.`cargo check --features cuda-stub`\n\nworks for type-checking only.**ARM (aarch64-linux):** in theory supported by Jetson; not tested.\n\n```\ngit clone https://github.com/craton-co/craton-bolt\ncd craton-bolt\ncargo build --release\n```\n\nHosts without a CUDA toolkit can type-check the crate with `cargo build --no-default-features --features cuda-stub`\n\n— useful for CI and `docs.rs`\n\nbuilds.\n\n```\nuse std::sync::Arc;\nuse arrow_array::{Float64Array, Int32Array, RecordBatch};\nuse arrow_schema::{DataType, Field, Schema};\nuse craton_bolt::Engine;\n\nlet mut engine = Engine::new()?;\n\n// Register a table.\nlet region: Int32Array = (0..1_000_000_i32).map(|i| i % 4).collect();\nlet price:  Float64Array = (0..1_000_000_u64).map(|i| i as f64).collect();\nlet tax:    Float64Array = (0..1_000_000_u64).map(|_| 0.0825_f64).collect();\nlet schema = Arc::new(Schema::new(vec![\n    Field::new(\"region_id\", DataType::Int32,   false),\n    Field::new(\"price\",     DataType::Float64, false),\n    Field::new(\"tax\",       DataType::Float64, false),\n]));\nlet batch = RecordBatch::try_new(schema, vec![Arc::new(region), Arc::new(price), Arc::new(tax)])?;\nengine.register_table(\"sales\", batch)?;\n\n// Execute.\nlet handle = engine.sql(\"SELECT price * tax FROM sales WHERE region_id = 1\")?;\nprintln!(\"got {} rows\", handle.num_rows());\n```\n\nBehind the scenes for that single line: the SQL is parsed; column references and string literals are rewritten as needed; the logical plan is lowered to a `KernelSpec`\n\nof SSA-shaped ops; the codegen emits a fresh PTX module; the CUDA driver assembles it to SASS; the kernel launches one thread per row with predicate gating; a GPU-side prefix-scan + gather compacts the output; the surviving rows download into an Arrow `RecordBatch`\n\n.\n\n```\n                ┌────────── SQL string ──────────┐\n                │                                │\n                ▼                                ▼\n        sqlparser (3rd-party)            DataFrame builder\n                │                                │\n                └─────────────┬──────────────────┘\n                              ▼\n                       LogicalPlan AST\n                              │\n                              │  string-literal rewrite\n                              │  (col = 'X' → __idx_col = i32(idx))\n                              ▼\n                       LogicalPlan\n                              │\n                              │  physical-plan lowering\n                              │  (resolve columns to ordinals, expressions to Op IR)\n                              ▼\n                       PhysicalPlan\n                              │\n                              ├── Projection { KernelSpec, ... }\n                              └── Aggregate  { pre?, AggregateSpec }\n                              │\n                              │  per-shape executor selection\n                              ▼\n                ┌──────────────────────────────────────────────┐\n                │  PTX codegen (per kernel)                     │\n                │   - projection kernel                         │\n                │   - predicate-only kernel                     │\n                │   - per-block reduction (SUM / MIN / MAX / …) │\n                │   - GROUP BY hash insert + per-aggregate      │\n                │   - float MIN/MAX via atom.cas                │\n                │   - prefix scan + gather                      │\n                └──────────────────────────────────────────────┘\n                              │\n                              │  CudaModule::from_ptx (calls cuModuleLoadData)\n                              ▼\n                       cuLaunchKernel\n                              │\n                              │  download outputs → arrow_array\n                              ▼\n                        RecordBatch\n```\n\nFor the long form, see [ docs/ARCHITECTURE.md](/craton-co/craton-bolt/blob/main/docs/ARCHITECTURE.md) and\n\n[.](/craton-co/craton-bolt/blob/main/docs/JIT_PIPELINE.md)\n\n`docs/JIT_PIPELINE.md`\n\nAll GPU numbers below were measured on an **NVIDIA GeForce RTX 2060**,\nCUDA 12.6, verified end-to-end equivalent against Polars 0.42 and DuckDB 1.2\nbefore timing. Full methodology and per-bench breakdown: [ docs/BENCHMARKS.md](/craton-co/craton-bolt/blob/main/docs/BENCHMARKS.md).\n\n**CPU-side overhead** (plan + lower + codegen, no GPU needed) is **sub-25 µs** per\nquery regardless of dataset size — JIT-compiling every query has negligible cost.\n\nThe tables below are illustrative; see [ docs/BENCHMARKS.md](/craton-co/craton-bolt/blob/main/docs/BENCHMARKS.md)\nfor the canonical numbers and methodology.\n\n| Query | Polars (CPU MT) | Craton Bolt (GPU) | Speedup |\n|---|---|---|---|\n| 11-op arithmetic chain (50 M rows) | 4.05 s | 124.8 ms |\n32.4× |\n| Filter + 4-op arithmetic (50 M rows) | 369 ms | 41.8 ms |\n8.8× |\n\n| Query | DuckDB | Polars | Craton Bolt | Notes |\n|---|---|---|---|---|\n| q1 low-card SUM (100 groups) | 6.9 ms | 19.0 ms | 51.4 ms |\nDuckDB wins |\n| q2 med-card 2-SUM (10 K groups) | 46.4 ms | 99.4 ms | 384 ms | DuckDB wins |\n| q3 two-key SUM (~1 M groups) | 498 ms | 385 ms | 219 ms ⭐ |\nCraton Bolt fastest |\n| q4 low-card 3-AVG (100 groups) | 12.9 ms | 97.0 ms | 70.5 ms |\nDuckDB wins |\n| q5 high-card SUM (1 M groups) | 623 ms | 358 ms | 237 ms ⭐ |\nCraton Bolt fastest |\n\nCraton Bolt wins outright on the two highest-cardinality workloads (q3, q5) where\nGPU-parallel hash-partitioning outpaces CPU per-core hash tables. CPU-native engines\nwin at low cardinality (q1, q4) where their per-thread L1-resident tables beat GPU\natomic contention. See [ docs/BENCHMARKS.md §honest read](/craton-co/craton-bolt/blob/main/docs/BENCHMARKS.md#the-honest-read)\nfor the full analysis.\n\n```\ncargo bench                              # CPU-only (plan, codegen, CPU ref, Polars)\nBOLT_BENCH_GPU=1 cargo bench            # add the GPU engine path\n```\n\nSee [ CONTRIBUTING.md](/craton-co/craton-bolt/blob/main/CONTRIBUTING.md). All non-trivial changes should come with tests; the build machine doesn't have a GPU, so PTX-shape assertions (the \"compile and search the emitted string\") are an acceptable substitute for the JIT layer, and\n\n`#[ignore]`\n\n-gated tests are the convention for live-GPU integration. See [for the full workflow.](/craton-co/craton-bolt/blob/main/docs/DEVELOPMENT.md)\n\n`docs/DEVELOPMENT.md`\n\n```\ncraton-bolt/\n├── Cargo.toml\n├── README.md\n├── CONTRIBUTING.md\n├── RELEASING.md              # maintainer release checklist\n├── CODE_OF_CONDUCT.md\n├── SECURITY.md\n├── CHANGELOG.md\n├── ROADMAP.md\n├── docs/\n│   ├── INSTALL.md            # prerequisites, build configs, troubleshooting\n│   ├── USER_GUIDE.md         # end-to-end usage walkthrough\n│   ├── ARCHITECTURE.md       # the layer cake and module map\n│   ├── JIT_PIPELINE.md       # SQL → PTX, step by step\n│   ├── SQL_REFERENCE.md      # what works, what doesn't\n│   ├── API_SURFACE.md        # public API reference\n│   ├── ENV_VARS.md           # environment variables and tuning knobs\n│   ├── DEVELOPMENT.md        # building, testing, benchmarking\n│   ├── FAQ.md                # frequently asked questions\n│   ├── BENCHMARKS.md         # measured numbers and methodology\n│   ├── COMPETITIVE_BENCHMARKING.md  # how to run fair comparisons\n│   ├── GROUPBY_PERF.md       # GROUP BY kernel design and analysis\n│   ├── LIMITATIONS.md        # requirements, pre-1.0 caveats, known gaps\n│   ├── MIGRATION_GUIDE.md    # upgrading across breaking changes\n│   └── PATH_TO_1.0.md        # detailed 1.0 milestone plan\n├── src/\n│   ├── lib.rs                # crate root, public re-exports\n│   ├── error.rs              # BoltError + BoltResult\n│   ├── cuda/                 # driver FFI, GpuVec, dictionaries\n│   ├── plan/                 # AST, DataFrame, SQL frontend, physical IR\n│   ├── jit/                  # PTX codegen + module loader\n│   └── exec/                 # per-shape executors + top-level Engine\n├── tests/                   # integration tests: parser, optimizer, aggregates,\n│                            #   joins, sorts, GROUP BY paths, string fns, casts,\n│                            #   datetime/decimal types, set ops, PTX golden\n│                            #   snapshots, proptest fuzzing, DuckDB cross-checks\n└── benches/\n    ├── query_benchmarks.rs   # criterion + Polars + CPU-ref (small dataset)\n    └── olap_benchmarks.rs    # h2o.ai groupby vs Polars vs DuckDB\n```\n\nSecurity issues should be reported privately per the policy in [SECURITY.md](/craton-co/craton-bolt/blob/main/SECURITY.md). Do not file public GitHub issues for vulnerabilities.\n\nVersion history and per-release notes live in [ CHANGELOG.md](/craton-co/craton-bolt/blob/main/CHANGELOG.md). Craton Bolt follows\n\n[Semantic Versioning](https://semver.org/); pre-1.0 the public API is unstable and minor bumps may break it.\n\nCraton Bolt stands on the shoulders of [ arrow-rs](https://github.com/apache/arrow-rs) (columnar memory format),\n\n[(SQL frontend), and NVIDIA's CUDA driver (everything below](https://github.com/apache/datafusion-sqlparser-rs)\n\n`sqlparser-rs`\n\n`cuModuleLoadData`\n\n).*Craton* and *Bolt* are trademarks of Craton Software Company.\n\nLicensed under the [Apache License, Version 2.0](/craton-co/craton-bolt/blob/main/LICENSE).\n\nBy contributing to Craton Bolt, you agree that your contributions will be\nlicensed under the same Apache-2.0 license. See [ CONTRIBUTING.md](/craton-co/craton-bolt/blob/main/CONTRIBUTING.md)\nfor details.", "url": "https://wpnews.pro/news/show-hn-craton-bolt-a-pure-rust-jit-compiled-gpu-sql-engine", "canonical_source": "https://github.com/craton-co/craton-bolt", "published_at": "2026-08-18 18:00:22+00:00", "updated_at": "2026-08-18 18:11:11.913478+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "developer-tools"], "entities": ["Craton Bolt", "NVIDIA", "CUDA", "Rust", "PTX", "RAPIDS", "cuDF", "Polars"], "alternates": {"html": "https://wpnews.pro/news/show-hn-craton-bolt-a-pure-rust-jit-compiled-gpu-sql-engine", "markdown": "https://wpnews.pro/news/show-hn-craton-bolt-a-pure-rust-jit-compiled-gpu-sql-engine.md", "text": "https://wpnews.pro/news/show-hn-craton-bolt-a-pure-rust-jit-compiled-gpu-sql-engine.txt", "jsonld": "https://wpnews.pro/news/show-hn-craton-bolt-a-pure-rust-jit-compiled-gpu-sql-engine.jsonld"}}