Core-Native Data Execution

Maximized
GPU Utilization.

Up to 50% more effective capacity from the AI infrastructure you already own.

CORNDEX turns GPUs into a high-performance execution layer for the data-intensive workloads behind AI and advanced analytics.

In production today, with one of the world's leading HBM manufacturers.
The problem

$680B of GPUs bought since 2024. About $400B of it is underutilized.

Modern AI runs on massively parallel GPUs, fed by data pipelines designed for the CPU era. Every stage of a pipeline crosses between CPU and GPU, and the GPU waits at every crossing. The meter runs either way.

~40%
typical share of the paid GPU hour actually spent computing
60%
of the paid hour is idle at that baseline
2.5x
the cost of every unit of useful work at 40% utilization

Effective Compute Utilization (ECU): the share of a paid GPU hour actually spent computing, from GPU-busy telemetry (an operational proxy). Published numbers range from 5% to below 70% at peak.

Why GPUs sit idle

Idle GPUs are waiting for data.

Microsoft Research classified 706 root causes across 400 production jobs that ran below 50% GPU utilization.

Data transfer and preparation
37%
Batch size and memory limits
29%
Saving results and checkpoints
18%
Moving data between GPUs
7%
GPUs held but not used
5%
Framework and library issues
4%

Nearly two thirds of the causes are data in motion, not computation.

Microsoft Research, ICSE 2024: 400 production deep learning jobs below 50% GPU utilization, 706 classified root causes, 85% of them fixable.

The solution

GPU-accelerated makes many trips.
GPU-native makes only one.

CORNDEX is a data engine that runs inside the GPU: scan, SQL, Python and machine learning as one pipeline, in one process. Data crosses from CPU to GPU once.

GPU-accelerated · the plugin approach
CPU GPU CPU GPU CPU GPU CPU

Six road trips per pipeline, and the GPU waits on every one of them.

GPU-native · CORNDEX
CPU GPU: scan → SQL → Python → ML → answer

One trip in. One answer out. The GPU never stands idle.

One engine for the whole path

Scan, SQL, Python and ML run as a single pipeline. No hand-offs between separate systems, no glue code between engines.

Built GPU-first

The optimizer, the runtime and the storage path were designed for the GPU, not adapted to it.

Standard interfaces

SQL and Python, Parquet and Iceberg. Teams keep their tools and their data formats.

Runs where the data lives

On-prem, private cloud, and air-gapped environments.

In production today

Before and after, on the fab floor.

High Bandwidth Memory is the memory inside every AI GPU. The market is sold out and every unit is pre-sold: yield is not a quality metric, it is revenue. When yield drops, engineers investigate the production test data to find the cause.

Before · CPU stack

Batch investigation

A question joined the overnight queue. The answer came back the next day.

With CORNDEX

Interactive

The same investigations run 5-10x faster. Engineers drill through billions of records live.

5-10x
faster execution, measured across the converted workloads. Not one cherry-picked query: the speedup is what turned the batch workflow into an interactive one.

Every multiple of speed is a shorter loop from detection to fix. That is the metric the fab runs on.

Every memory generation stacks higher and starts below the maturity of the one before it. The yield climb restarts each time, so the investigation loop is a standing requirement, not a project.

Long term

The data layer of accelerated computing.

Wherever a GPU works on data, the engine underneath is CORNDEX. CPUs orchestrate. GPUs execute.