NVIDIA Kumo Relational Outperforms Supervised Machine Learning on Relational Data, No Training Required

TL;DR

NVIDIA Kumo Relational is a pre-trained relational foundation model that makes predictions directly on enterprise databases. Given a predictive query, it gathers historical examples as context examples and predicts outcomes such as churn, demand, or fraud in a single forward pass. It needs no task-specific training, no feature engineering, and no flattening of tables. Kumo Relational is the first few-shot foundation model to outperform supervised machine learning on common relational benchmarks. Across 41 tasks on 15 databases, it beats supervised relational deep learning models and expert-engineered gradient-boosted tree pipelines, and on the SAP SALT enterprise benchmark it surpasses AutoGluon ensembles by 8% in mean reciprocal rank (MRR). It scales to databases with 500B+ rows and works for humans and agents alike, through NVIDIA's open-source, GPU-native structured-data-models and kumo-engine libraries, or as an NVIDIA NIM.

- Paper: https://arxiv.org/abs/2604.12596

- Model Code: https://github.com/NVIDIA/structured-data-models

- Model Weights: https://huggingface.co/nvidia/Kumo-Relational

- Client Code: https://github.com/NVIDIA/structured-data-models-client

- NIM Documentation: https://docs.nvidia.com/sdgm/rfm/overview

The Shift to Structured Data Foundation Models

Foundation models have already rewritten the playbook for language and vision. Not long ago, production NLP meant a dedicated model per task, each fed by its own pipeline of tokenization, lemmatization, and n-grams. LLMs made that stack largely obsolete for three reasons: they were more accurate than the best task-specific models, far simpler to put into production, and flexible enough to open a new era of agentic applications.

The same shift is now underway for structured data. Relational databases power the world's most critical business decisions, yet predictive modeling on them still requires weeks of feature engineering, task-specific training, and tuned pipelines. Structured data foundation models change that for the same three reasons:

Better accuracy today: As drop-in replacements, these models already beat many production pipelines, especially XGBoost. On RelBench V1 classification tasks, Kumo Relational outperforms gradient-boosted trees on expert-engineered features by nearly 4 AUROC points on average. On SAP SALT, it beats XGBoost on engineered features by 7 MRR points out of the box and by 13 MRR points after fine-tuning. These results make a compelling case for replacing production XGBoost pipelines with Kumo Relational.

Simplicity and agility: One pre-trained model replaces separate pipelines for individual tasks. A new prediction becomes a query instead of a project, so ML teams can finally take on use cases that traditional ML made too laborious to build at every level of the organization.

Agents that can predict: LLMs let agents read, write, and reason. Structured data foundation models let them anticipate what happens next, such as which customer will churn, and act on it. Kumo Relational is already built to be called by agents, and its Predictive Query Language (PQL) gives them a simple interface for asking predictive questions.

Today, we are introducing Kumo Relational ( Paper , GitHub , HuggingFace ), a pre-trained foundation model that brings this paradigm to relational data. Connect a database, describe what to predict, and get predictions in a single forward pass. No training required.

How Kumo Relational Works

Most foundation models for structured data operate on a single flat table. Real-world data lives in relational databases instead: users connected to orders connected to products, all evolving over time. Flattening these relationships into one row through manual aggregation ( e.g. , "average order value in the last 30 days") loses fine-grained structural signals and takes significant human effort.

Kumo Relational is a Relational Foundation Model that operates directly on the database, respecting its tables, foreign keys, and timestamps. It is pre-trained once on synthetic relational data that reflects real-world datasets and adapts to each new task through in-context learning by reasoning over context examples at inference time. Each example pairs a local subgraph around an entity at a point in time with its ground-truth target ( e.g. , "this user churned" or "this item sold 142 units").

Figure 1. Overview of the Kumo Relational system. Connect a database, specify a predictive query, and Kumo Relational handles the rest, from context generation to model inference.

To make a prediction, Kumo Relational has to do three things: (1) understand the values within each table, (2) relate records across tables, and (3) relate context examples with known targets to the entity being predicted. Here is how it works:

Figure 2. Kumo Relational architecture: (a) context input, (b) reasoning within tables, (c) reasoning across tables.

Automatic Context Generation: Tasks are written in the Predictive Query Language (PQL) , a declarative interface where you state what to predict rather than how. For temporal tasks, Kumo Relational replays historical database states: it samples entity-centric subgraphs up to an anchor timestamp and computes each target from events after that timestamp, while serving the model only the data from before it. This prevents data leakage.

Reasoning Within Tables: A lightweight network processes each table independently via column attention (relating values within a column) and row attention (relating features within a row). The model learns which columns and rows matter for the current prediction and filters out noise before it propagates.

Reasoning Across Tables: A larger network distributes the row embeddings across the relational structure via graph attention over primary-key/foreign-key relationships, followed by cross-sample attention across context examples. This is where relational reasoning happens, such as linking a user's profile to their transaction history. Because this stage works on row embeddings rather than on every cell in every table, the design avoids quadratic cost and scales to large contexts and deeper subgraphs.

How Kumo Relational Was Built