For more than a decade, NPAW has measured video. Every play, every rebuffer, every second of watch time, across streaming services on every continent. It adds up to billions of events, and the questions people ask of those events are not the easy kind.
“How many people were watching at the same time during the final?” is a question about overlapping intervals over every session. “Where in the funnel do viewers drop?” is a question about ordered sequences per user. “At which minute does the audience leave?” is a question about seeks and stops relative to a timeline. None of them decomposes into a pre-aggregated cube without losing the thing that makes them interesting.
We did what everyone does
We answered them the way the industry answers them: with the best CPU columnar engines available, plus cubes, pre-aggregation and sampling where the engines ran out of road. This worked. It also cost a little more every year and answered a little less: every new question needed a new cube, every cube needed a pipeline, and every pipeline had an owner who eventually left.
At some point we stopped blaming the software. The engines we used were excellent — the summit of fifteen years of squeezing the CPU. Columnar layouts, vectorized execution, SIMD, compression: all of it exists to feed a handful of cores as efficiently as physics allows, and physics had been reached. The problem was the hardware tier.
The other tier
An analytical query is mostly a bandwidth problem: scan a column, filter it, aggregate it, join it. A high-end server socket moves a few hundred gigabytes per second from memory, shared across all its cores. A single consumer GPU moves a terabyte per second, through thousands of cores that are built for exactly the data-parallel work relational operators are made of. A node with eight of them has more aggregate bandwidth than a rack of CPU servers, in a footprint one team can understand.
GPU databases were not a new idea. They had existed for a decade and proved the thesis. They had also stayed proprietary, priced for a handful of large accounts, and foreign to the SQL ecosystem most teams already lived in. We had never seriously tried one, and we were a company whose entire business is analytics.
Building for the device
So we built an engine for the other tier. In Rust, with CUDA kernels, with storage laid out for the GPU rather than adapted to it, with one GPU per worker so that capacity is a count and not a tuning exercise. We kept the boring parts boring: a write-ahead log, replication, backup and restore, authentication, metrics. And we kept the SQL: joins, CTEs, subqueries, a ClickHouse-compatible layer so that the first query usually runs unchanged.
Two things surprised us. The first is that living on the GPU puts machine learning next to the data almost for free: a forecast or an anomaly score becomes a table function in the query, running on the same device, instead of a pipeline. The second is how general the result is. We built it for video. It turned out to be a database.
What happens next
RayoDB is now a product of NPAW, and we are opening it to a small group of design partners. We will publish what we can prove and nothing else — you will not find a performance number on our site until it comes with the artifact that produced it. If you run analytics on billions of events and want to see what the GPU changes, talk to us.