Product
What RayoDB is today.
Everything on this page is shipped and documented. Nothing here is a roadmap item — those we keep in a separate, honest list at the bottom.
Engine
Rust + CUDA, from the parser to the kernel.
The query engine is written in Rust and executes on NVIDIA GPUs through CUDA kernels. Filters, aggregations, joins, top-k and partitioning run on the device; a fused filter-plus-aggregate path reads the data once and keeps it there until the answer is ready.
- Rust + CUDA execution engine with filter, aggregate, join, top-k and partition kernels.
- One GPU per worker process; as many workers as you need.
Storage
Columnar segments designed for GPU residency.
Data lives in compressed columnar segments with per-block zone maps and dictionary encoding, so a query skips what it does not need and uploads what it does in a device-friendly layout. Manifests are atomic; the write-ahead log makes ingestion durable; background scrubbing verifies checksums.
- Columnar segments with zone maps, dictionary encoding, adaptive zstd compression, atomic manifests and WAL-backed durability.
- Partition-level data retention (TTL) for time-partitioned tables, manifest-driven and crash-safe.
Distributed
A coordinator, N workers, one GPU each.
Tables are sharded by hash or by time across workers. Replication is configurable per table, reads fail over to replicas, shards can be repaired and rebalanced online, and the whole cluster can be backed up and restored.
- One coordinator, N workers, hash- or time-sharded tables, configurable replication with read failover, shard repair, online rebalance, cluster-wide backup/restore.
Ingestion
Bulk, continuous, or streaming — exactly once.
Load files in bulk, watch a directory, post rows to the ingest API, or attach managed stream sources. Kafka, MySQL and PostgreSQL sources are exactly-once, with a WAL-backed delta store for micro-batches and partition-level retention.
- Exactly-once managed stream sources from Kafka and from MySQL/PostgreSQL via watermark polling; WAL-backed delta store for micro-batches.
SQL
The SQL you already write.
Joins, correlated subqueries, common table expressions, window-style aggregates and a large scalar and aggregate catalog. A ClickHouse-compatible layer accepts the functions and syntax many teams already use, so the first query usually runs unchanged.
- Joins, correlated subqueries, CTEs and an extensive aggregate/function catalog; DELETE and UPDATE by predicate, also in distributed mode.
- A ClickHouse-compatible scalar function batch and a ClickHouse syntax-tolerance layer.
- Video-analytics aggregates: FUNNEL, CONCURRENT_SESSIONS, AUDIENCE_RETENTION, CONVERSION_JOURNEYS, EVENT_PATHS.
WITH sessions AS (
SELECT user_id, session_id, min(ts) AS started, max(ts) AS ended
FROM view_events
WHERE ts >= toStartOfDay(now() - INTERVAL 1 DAY)
GROUP BY user_id, session_id
)
SELECT
p.plan,
count() AS sessions,
avg(ended - started) AS avg_duration
FROM sessions s
JOIN plans p ON p.user_id = s.user_id
GROUP BY p.plan
ORDER BY sessions DESC;Migration
Query your ClickHouse, PostgreSQL and MySQL tables in place.
External tables let RayoDB read tables that live in other systems — pass-through or cached — with predicate pushdown and full join support against native tables. Start with the queries that hurt, keep the rest where it is, and move data when you are ready.
- ClickHouse, PostgreSQL and MySQL tables queried in place (pass-through or cached) with predicate pushdown and full join support.
AI in SQL
Forecasts, anomalies, embeddings — as functions.
AI_FORECAST and AI_DETECT_ANOMALIES are table functions over any series you can select; AI_EMBED and AI_SIMILARITY turn text into vectors and compare them. Built-in baselines work with zero setup; ONNX models registered with CREATE AI MODEL serve on the GPU.
- AI_EMBED, AI_SIMILARITY, AI_FORECAST and AI_DETECT_ANOMALIES as SQL functions, served by built-in baselines or ONNX models with GPU inference, managed with CREATE AI MODEL.
CREATE AI MODEL chronos_bolt TASK FORECAST BACKEND ONNX PATH '/models/chronos-bolt-small';
SELECT * FROM AI_FORECAST(hourly_plays, hour, plays, 24, '0.1,0.5,0.9', 'chronos_bolt');
SELECT title, AI_SIMILARITY(AI_EMBED(title), AI_EMBED('live football final')) AS score
FROM catalog
ORDER BY score DESC
LIMIT 10;Operations
Boring where it should be.
Validated configuration with a typed inventory of every knob, authentication with per-route permissions, TLS, Prometheus metrics, health and readiness probes. The things an operator expects from a database, present from the first deployment.
- Validated TOML configuration, typed inventory of every environment knob, JWT/API-key/Basic authentication with per-route permissions, TLS, Prometheus metrics, health and readiness probes.
Not yet
What RayoDB does not have.
An honest list. We would rather you learn this here than in an evaluation.
- Tables are created and dropped through the REST API, not with SQL DDL (the AI model catalog is the exception).
- No UNION / INTERSECT / EXCEPT, no recursive CTEs, no multi-statement requests.
- No general-purpose OLTP: mutations are batch/analytical, there are no row-level transactions across statements.
- No published cross-engine performance numbers yet — by policy, not by accident.
See it on your data.
Early-access partners get a guided setup, direct access to the engineers, and a say in what comes next.