GPU-native analytics database · Early access

GPU-native analytics.
SQL you already know.

RayoDB is a distributed analytics database that runs your SQL on GPUs — built for billions of events, interactive answers, and AI inside the query.

The thesis

Analytics is about to change hardware.

  1. The CPU road is ending.

    Fifteen years of columnar engines squeezed everything out of the CPU. Per-core gains are flat; scaling out multiplies cost and operational load.

  2. The GPU is the next order of magnitude.

    Thousands of cores and terabytes per second of memory bandwidth are exactly what scans, joins and aggregations want.

  3. Nobody made it accessible.

    GPU databases stayed proprietary and far from the SQL ecosystem most teams already use. RayoDB changes that.

Read the full thesis →

What RayoDB is

A GPU-native analytics database with the SQL you already know.

Four things that are true today, not on a roadmap.

  • Built on the GPU, not ported to it.

    A Rust + CUDA execution engine and columnar storage designed for GPU residency. One GPU per worker, as many workers as you need.

  • Distributed and durable.

    Sharded tables, configurable replication with read failover, cluster-wide backup and restore, write-ahead logging. A database, not a demo.

  • Your SQL, your tools.

    Joins, CTEs, subqueries and a large function catalog. A ClickHouse-compatible syntax layer, and external tables on ClickHouse, PostgreSQL and MySQL.

  • AI where the data is.

    AI_FORECAST, AI_DETECT_ANOMALIES, AI_EMBED and AI_SIMILARITY as SQL functions, backed by an ONNX model catalog you manage with CREATE AI MODEL.

Show me

Two statements, one session.

Aggregate a week of events into an hourly series, then forecast the next day — in SQL, on the GPUs, with a model that runs where the data is.

rayodb — sample sessionsample data

1 · aggregate a week of plays per hour, straight from the events

SELECT toStartOfHour(ts) AS hour, count() AS plays
FROM view_events
WHERE ts >= now() - INTERVAL 7 DAY
GROUP BY hour
ORDER BY hour;
hourplays
2026-08-27 00:00:001,284,913
2026-08-27 01:00:00962,340
2026-08-27 02:00:00701,118
2026-09-02 23:00:001,633,207

168 rows · 8 workers · 8 GPUs · sample data

2 · forecast the next 24 hours from that series — in SQL

SELECT * FROM AI_FORECAST(hourly_plays, hour, plays, 24);
tsforecastq10q90
2026-09-03 00:00:001,301,5401,214,0021,388,118
2026-09-03 01:00:00978,116901,4551,054,210
2026-09-03 02:00:00712,904650,318775,006
2026-09-03 23:00:001,657,9321,540,4701,775,391

24 rows · 8 workers · 8 GPUs · sample data

Sample data. The statements are real RayoDB SQL; the rows are illustrative. We do not show timings here — here is why.

Why believe it

Three plain facts.

Born inside NPAW.
Built on video analytics at the scale of billions of events, by a team that has run large analytics infrastructure for years. Our story →
Engineered like a database.
WAL durability, replicas, backup and restore, authentication, TLS, metrics and a typed configuration inventory — from day one. What is inside →
We publish what we can prove.
No benchmark number appears on this site without a versioned artifact and a methodology you can reproduce. Our evidence policy →

We are opening the door to a small group of design partners.

Early access means direct access to the team, influence on the roadmap, and the first production deployments. If you run analytics on billions of events and want to see what the GPU changes, talk to us.