Built for sustained analytical performance.
Response time, concurrent capacity and operational efficiency are designed together rather than added after deployment.
The system, area by area.
- Execution
- Filtering, grouping, joining and ranking run on the GPU, with the data kept there between steps.
- Hardware
- One GPU per worker. Capacity grows by adding workers.
- Storage
- Columnar, compressed storage that reads only the fields a query names. Loads are crash-safe.
- Scale and resilience
- Tables spread across machines with as many copies as needed; reads survive a failure; whole-cluster backup and restore.
- SQL
- Joins, subqueries, reusable query blocks and an extensive function catalog.
- Compatibility
- ClickHouse queries run as they are, through a compatibility layer.
- Existing systems
- Tables still in ClickHouse, PostgreSQL or MySQL are queried in place and joined with RayoDB tables.
- Getting data in
- Live sources from Kafka, MySQL and PostgreSQL that never count a row twice, plus bulk and API loading.
- Retention
- Data older than a chosen window is dropped on schedule.
- AI in SQL
- Forecasting, anomaly detection and search by meaning as SQL functions, with built-in models or your own.
- Session analytics
- Session measures as SQL functions: funnels, concurrent activity, retention and event paths.
- Operations
- Accounts and API keys with permissions, encrypted connections, Prometheus metrics and health checks.
Questions every evaluation asks.
- Does existing SQL need rewriting?
- Rarely. Joins, subqueries and the usual functions are supported, and ClickHouse queries run as they are. What is missing is listed below.
- Does the data have to move first?
- No. Tables still in ClickHouse, PostgreSQL or MySQL can be queried in place, so an evaluation starts with the queries that hurt today.
- What hardware does it need?
- NVIDIA GPUs, one per worker. The development cluster runs eight consumer cards per machine, hardware a team can buy.Why GPUs
- Where does it run?
- On your own machines or cloud GPU instances, inside your network. There is no hosted service during early access.
- How does it perform?
- Every evaluation measures response time, concurrent capacity and infrastructure against the system already running the same workload.Performance methodology
What RayoDB does not have.
- Tables are created through the API, not with CREATE TABLE in SQL.
- No UNION, INTERSECT or EXCEPT, no recursive queries, one statement per request.
- Not a transactional database: built for analysis, not for orders row by row.
- General performance comparisons will follow the broader benchmark program.
Measure your workload.
Early-access partners compare RayoDB with their current system using their data and queries.