What happens when a model predicts on your database without training?

How the model reads a database instead of a flat table

Most production pipelines still flatten users, orders, and products into one wide row. Engineers spend weeks writing aggregations like average order value in the last thirty days. That process throws away the fine-grained structure that lives in foreign keys and timestamps. Kumo Relational skips the flattening step entirely. It connects to the database as it is, with tables, keys, and time intact.

A predictive query written in PQL tells the system what to predict, not how. For temporal tasks the engine replays historical database states. It samples entity-centric subgraphs up to an anchor timestamp and computes each target from events after that timestamp. The model sees only data from before the anchor. This prevents data leakage by construction.

Inside the model, reasoning happens in two stages. A lightweight network processes each table independently, alternating column attention and row attention. It learns which columns and rows matter for the current prediction and filters out noise before it propagates. A larger network then distributes the row embeddings across the relational structure via graph attention over primary-key and foreign-key relationships, interleaved with cross-sample attention across context examples. Because this stage works on row embeddings rather than on every cell, the design avoids quadratic cost and scales to large contexts and deeper subgraphs.

What the benchmarks actually show

The paper evaluates Kumo Relational on 41 benchmarks across 15 relational databases from RelBench V1 and V2, SAP SALT, and 4DBInfer. None of these datasets were seen during pre-training. On RelBench V1 classification tasks, the model outperforms gradient-boosted trees on expert-engineered features by nearly 4 AUROC points on average. On the SAP SALT enterprise benchmark, it beats XGBoost on engineered features by 7 MRR points out of the box and by 13 MRR points after fine-tuning. It also surpasses large AutoGluon ensembles by 8 percent in mean reciprocal rank, and recent tabular foundation models by about 25 percent. Fine-tuning extends the lead over AutoGluon to 16 percent.

Speed matters as much as accuracy. On the RelArena-α leaderboard, which compares relational models and systems on RelBench V1, Kumo Relational sits on the accuracy-efficiency Pareto front out of the box at about 17 seconds and Elo 1,842. The highest-scoring entry, rt-plurel, reaches Elo 1,878 at about 7,300 seconds, roughly 430 times slower. Every other foundation model, feature-engineering system, and supervised model scores lower and runs slower.

Robustness checks reveal additional margins. The model performs well with as little as 0.2 percent of the training data as context. It stays stable when up to 75 percent of foreign-key links are removed. It barely degrades when many noisy columns are added.

Where it fits in your stack

Kumo Relational runs in-context learning natively over databases. It works in memory, through database and warehouse connectors, or through a custom graph engine that handles 500B+ rows via memory-mapped I/O at up to 5 GB/s. The model is available in NVIDIA's newly released, GPU-native structured-data-models library, the same open-source library that powers Kumo Tabular. The library downloads the weights from the Hugging Face Hub on first use, so you can load the model in a GPU-backed notebook and predict directly from it.

To run the model as a separate service instead, deploy it as an NVIDIA NIM and point the open-source structured-data-models-client at it from your notebook. You write the prediction in PQL, and the client gathers the context examples and related tables, then sends the request. The code is released under the Apache 2.0 license and the model weights under the OpenMDW License Agreement, version 1.1.

What the model still cannot do

The model performs best on data with meaningful relationships and temporal dynamics, such as user behavior over time. On tasks with very large training sets, task-specific supervised models may still edge out in-context predictions, which used at most 10,000 context examples in the benchmarks. Fine-tuning of the foundation model is designed for exactly this case. Predictive signals must also be reachable within a limited number of hops, so the documentation advises starting with a focused query over a few relevant tables and expanding the graph as needed. The announcement does not say how many of the 500B-row deployments are currently in production.