NVIDIA Kumo Relational Beats Supervised ML on 41 Tasks Without Any Training

NVIDIA has published Kumo Relational, a pretrained relational foundation model that makes predictions directly on top of an enterprise database. The user describes what to predict and gets a result in a single forward pass, with no task-specific training, no manual aggregates and no flattening of tables. On 41 tasks across 15 databases, the model beat supervised models and gradient boosting on expert-built features. On SAP SALT it outperforms large AutoGluon ensembles by 8% in mean reciprocal rank. The authors include Jure Leskovec and Matthias Fey, and the work was done together with the Kumo team.

Prediction as a query, not a project

The usual route for a task like customer churn takes weeks. Engineers compute "average order value over 30 days," join users, orders and products into a single row, tune XGBoost and maintain the pipeline. Kumo Relational works differently: it reads tables, foreign keys and timestamps as they are. The task is written in Predictive Query Language, for example `PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id`.

The system assembles the context itself. It takes historical examples, cuts a local subgraph around each entity as of a given point in time, and attaches the known outcome, such as "the user churned" or "the product sold 142 times." For temporal tasks, the database is replayed through its historical states: the model sees only data up to the anchor timestamp, while the target is computed from events after it. Leakage of future data is ruled out by construction.

The architecture has two stages. A lightweight network processes each table separately through column attention and row attention and filters out noise. A larger network then propagates row embeddings across the database structure via graph attention over primary- and foreign-key links, followed by cross-sample attention between context examples. Because the second stage operates on row embeddings rather than on every cell, there is no quadratic cost, and contexts with deep subgraphs stay manageable.

Synthetic data instead of proprietary databases

There are almost no diverse relational databases available in the open for pretraining, so the model is trained entirely on synthetic data. The generator builds on PluRel (Kothapalli et al., ICML 2026) and creates a database in three steps: a schema, links between rows with realistic clustering, and column values drawn from structural causal models with temporal trends and cross-table dependencies. Generation is cheap, so the supply of pretraining data is practically unlimited. Loss falls as a power law as more databases are added, and the gains carry over to real data. Training proceeds in stages, from single tables to complex relational structures.

Evaluation used datasets the model had not seen: RelBench V1 and V2, SAP SALT and 4DBInfer. They cover e-commerce, medicine, enterprise, social networks and academic data.

• 41 tasks across 15 relational databases.
• RelBench V1, classification: about 4 AUROC points above gradient boosting on expert features.
• SAP SALT: 7 MRR points above out-of-the-box XGBoost on engineered features, and 13 points after fine-tuning.
• SAP SALT against large AutoGluon ensembles: plus 8% MRR, and plus 16% after fine-tuning.
• RelArena-α (leaderboard as of 21.09.2026): the model sits on the Pareto front of accuracy and speed, about 430 times faster than rtl-plurel at comparable accuracy.
• Robustness: works with 0.2% of training data in the context, holds up when up to 75% of foreign-key links are removed, and degrades very little when noise columns are added.
• Scale: kumo-engine processes databases of over 500 billion rows via memory-mapped I/O at up to 5 GB/s.

The authors state the limitations themselves. The model works best where there are meaningful relationships and temporal dynamics, such as user behavior. On tasks with very large training sets, specialized supervised models may win. The predictive signal must lie within a limited number of hops across the links.

How to run it and where to save

The main savings here are in engineering hours, not tokens. Instead of a separate pipeline for every task, there is one model and a set of queries. A new forecast becomes a line of PQL, and teams can take on use cases that previously did not justify the development cost. For agents, PQL serves as a simple interface: the LLM reads and reasons, while Kumo Relational supplies the prediction, such as which customer will churn.

There are three ways to run it. The first is the open, GPU-native structured-data-models library (`pip install structured-data-models`), where `sdm.models.KumoRelational(device="cuda")` accepts context tables, query tables and linked tables. Weights are pulled from Hugging Face Hub on first use. The second is deployment as an NVIDIA NIM with the structured-data-models-client, where a PQL query and a pandas DataFrame are turned into context automatically. The repository includes notebooks for a local NIM and for Databricks. The third is kumo-engine, with connectors to databases and data warehouses for large volumes.

The code is released under Apache 2.0 and the weights under the OpenMDW License Agreement 1.1. The practical test is simple: take a production XGBoost task, such as churn or demand, run it on Kumo Relational, and compare metrics and development time. If the signal in your data sits a couple of key hops away, you can most likely replace the pipeline.