Use cases

Questions that were too expensive to ask.

Three workloads where the GPU changes what is practical. Each one: the question, why it is hard today, and how it looks in RayoDB.

Video & streaming analytics · origin workload

Every play, not a sample.

The question: How many viewers were watching at the same time during the match? Where in the funnel do they drop? At which minute of the episode does the audience leave?
Why it is hard today: These are session-level questions over billions of events. On CPU engines they are answered from pre-aggregated cubes and samples, which means the question has to be known in advance — and the answer is approximate.
In RayoDB: RayoDB was born on this workload. Video-analytics aggregates are first-class SQL functions, computed on the GPU over the raw events and merged exactly across shards.
Who it is for: Streaming platforms, broadcasters, video analytics vendors, ad-tech for CTV.

-- peak concurrency, funnel and retention over all events, in SQL
SELECT
  CONCURRENT_SESSIONS(ts, event = 'start', event = 'stop')  AS concurrency,
  FUNNEL(ts, 30000,
         event = 'start', event = 'join', event = 'play',
         'level')                                             AS funnel,
  AUDIENCE_RETENTION(duration, play_time, seek_playhead,
                     event = 'stop', event = 'seek',
                     'mode=percent', 'buckets=20', 'unit=uniq') AS retention
FROM view_events
WHERE content_id = 'final-2026'
  AND ts BETWEEN '2026-06-14 19:00:00' AND '2026-06-14 23:00:00';

Three video-analytics aggregates over the raw events. Distributed and exact.

Product & event analytics

Any question, interactive.

The question: Which feature do users touch before they convert? How does retention differ by acquisition channel, by device, by week? What happened to the users who saw the new onboarding?
Why it is hard today: Event tables grow by billions of rows a month. Ad-hoc questions need joins between sessions, users and events, over long ranges, with arbitrary filters. That is exactly the shape that forces CPU engines into pre-computation.
In RayoDB: Joins, CTEs and subqueries execute on the GPU with the data resident there. Ask, look, refine, ask again — the loop stays interactive without deciding the questions upfront.
Who it is for: Product analytics teams, growth teams, data platforms serving internal dashboards.

WITH first_touch AS (
  SELECT user_id, min(ts) AS first_seen, any(channel) AS channel
  FROM events
  GROUP BY user_id
)
SELECT
  f.channel,
  toStartOfWeek(f.first_seen)  AS cohort,
  count(DISTINCT e.user_id)    AS active_week_4
FROM events e
JOIN first_touch f ON f.user_id = e.user_id
WHERE e.ts BETWEEN f.first_seen + INTERVAL 28 DAY
               AND f.first_seen + INTERVAL 35 DAY
GROUP BY f.channel, cohort
ORDER BY cohort, f.channel;

Week-4 retention by acquisition channel — a join over the raw events, no cube.

Time series with built-in intelligence

Forecast and detect in the same query.

The question: What will tomorrow look like? Which of these ten thousand series is misbehaving right now? Is this a real change or Tuesday?
Why it is hard today: Forecasting and anomaly detection usually live in a separate pipeline: export the series, run a model, write the result back. That pipeline is where freshness, ownership and correctness go to die.
In RayoDB: AI_FORECAST and AI_DETECT_ANOMALIES are table functions over any series you can select. Built-in baselines work with zero setup; an ONNX model registered with CREATE AI MODEL serves on the same GPUs that aggregate the data.
Who it is for: Observability and reliability teams, operations analytics, IoT and telemetry platforms.

-- score the last month of hourly errors and keep what is anomalous
SELECT ts, value, expected, score
FROM AI_DETECT_ANOMALIES(hourly_errors, hour, errors, 3.5)
WHERE is_anomaly
ORDER BY score DESC
LIMIT 20;

-- and the next 48 hours, with 10/50/90 quantile bands
SELECT * FROM AI_FORECAST(hourly_errors, hour, errors, 48, '0.1,0.5,0.9');

Anomaly scoring and forecasting as SQL — no export, no pipeline.

Have a workload like these?

Tell us about it. Early access is for teams with real data and real questions.

Request early access