Skip to main content

Welcome to Algeon

Algeon brings specialized GPU algorithms into composable SQL workflows over open data. Apache DataFusion is the first integration: supported SQL operations run on cuDF, while cuGraph and cuVS algorithms appear as SQL table functions that compose with joins, filters, and aggregations. You can embed the DataFusion adapter in a Rust application or connect through Arrow Flight SQL.

DuckDB is the next narrow adapter direction and Spark is a longer-term direction; neither is supported today.

GPU execution is opt-in per query: plans, or parts of plans, that Algeon does not select for GPU execution stay on the normal DataFusion CPU path with the same results. Once GPU execution starts, a failure is returned as a structured error and is not re-run on CPU. Selection normally replaces a whole candidate (with one certified mixed exception), and each run executes inside a fixed GPU memory grant.

Where to start​

To learn why we built Algeon, read Introducing Algeon.

Architecture at a glance​

A query enters through the interface you already use; the DataFusion optimizer rule decides which parts run on the GPU in the same process, and results return to that interface as ordinary Arrow batches. The lower arrows show where table data comes from: local Parquet files or Parquet in object storage.

Features​

  • GPU execution behind DataFusion APIs. Supported physical plans run on cuDF without changing your SQL, DataFrame code, or result format. You can require that a plan contain no CPU execution and have it rejected otherwise.
  • Graph and vector algorithms in SQL. cugraph_* table functions run PageRank, BFS, Louvain, ForceAtlas2, and other algorithms over relations; cuvs_* functions run exact kNN, KMeans, and PCA over vector columns. Both return ordinary rows.
  • Function discovery and validation. The GPU function catalog lists the functions installed in a session, describes each contract, validates a call before execution, and reports whether each function is executable.
  • Parquet sources. GPU scans read local and S3-compatible Parquet. Remote sources are read-only, with an optional local workspace for views and scratch tables. Iceberg is not supported in this release; see Iceberg support.
  • Answers before and after execution. algeon_explain_coverage (or EXPLAIN GPU over Flight SQL) tells you which parts of a query will run on the GPU and why the rest will not; errors carry stable machine-readable codes.

Current limitations​

  • A subset of SQL runs on the GPU. Unsupported operators, expressions, and Arrow types stay on the DataFusion path. See Native SQL Support and Data Type Support.
  • One GPU per query. Independent queries can be spread across configured GPUs, but a single query never spans devices.
  • No spilling. Each query runs inside the GPU memory cap it is granted; exceeding it returns an allocation error instead of spilling to host memory or disk in the style of cuCascade.
  • Algorithm coverage is fixed. Only the documented cuGraph and cuVS functions are available; unsupported types, options, and algorithms return structured planning errors. The cuVS surface is still growing, and the cuOpt SQL API is work in progress.
  • GPU file scans are Parquet-only. Iceberg position deletes are supported when their scan is otherwise supported; equality deletes, delete vectors, non-Parquet files, and other source types stay on the DataFusion path.

Next steps​

  • Integrating Algeon — choose between an embedded session and the Flight SQL server, then follow the common flow.
  • Discover & Validate GPU Functions — inspect the installed function families and their execution status.
  • Design — how Algeon fits into DataFusion, the crate layout, and the diagnostic contracts.
  • Reference — support boundaries, benchmarks, and the glossary.