Skip to main content

GPU Acceleration

A GPU can run thousands of operations at once, which is exactly the shape of heavy analytical work: filtering, aggregating, grouping, joining, and sorting across millions of rows. When a suitable GPU is available, ScramDB can offload this work to it and bring back the results, all as part of running your normal SQL.

Works across GPU vendors​

ScramDB's GPU acceleration is not tied to one brand of hardware. The same query operators are built to run on:

  • NVIDIA GPUs (data-center cards such as the A100 and H100 through to desktop cards).
  • AMD GPUs (including data-center accelerators such as the MI300X and desktop Radeon cards).
  • Apple Silicon through Metal (M-series chips).

So whether your servers carry data-center accelerators or your workstation is a recent Mac, the same acceleration path is available.

Automatic CPU fallback​

You never have to worry about whether a GPU is present or whether a given query suits it. ScramDB decides per query, and the rule is simple and safe: if the GPU is missing, busy, unhealthy, or a poor fit for the query, ScramDB runs that query on the CPU instead. It falls back cleanly rather than failing or slowing down, and the answer is always the same regardless of where it ran. There is no GPU-only mode that can leave a query stranded.

If the GPU hits an unrecoverable error, ScramDB marks it unhealthy for the rest of the process: every query runs on the CPU from that point on, rather than retrying the GPU query by query. A restart re-enables the GPU. This keeps a flaky or misbehaving GPU from ever turning into unpredictable per-query latency.

When the GPU helps​

GPU acceleration pays off most on large analytical queries: big scans with filters, group-by and aggregation over many rows, large joins, and sorts. By default, ScramDB only considers a query for the GPU once it involves at least 50,000 rows, so the small end of the workload never pays for a trip to the GPU it would not benefit from.

It is not meant for small, pinpoint transactional queries, such as looking up or updating a single row by key. Those are already fast on the CPU and would not benefit from the trip to the GPU, so ScramDB simply keeps them on the CPU.

Nothing to configure​

Like the rest of ScramDB, this is automatic. You write standard SQL, and ScramDB chooses the fastest safe way to run each query, GPU or CPU, without hints or special syntax.

If you want to turn GPU acceleration off entirely, for example to keep a machine CPU-only, set enabled = false in the [gpu] section of the config file:

[gpu]
enabled = false