NVIDIA Kumo Relational: A Foundation Model That Predicts Straight From Your Database, No Training

NVIDIA, with the team behind Kumo, has released a foundation model for a kind of data language models usually ignore: relational databases. The Hugging Face post introduces Kumo Relational, which predicts outcomes like churn, demand or fraud directly from linked tables, "in a single forward pass," with no task-specific training, no feature engineering and no flattening of tables. The accompanying paper is on arXiv.

The pitch is that structured-data models are following the path language models took: one pre-trained model replacing a pile of per-task pipelines. Whether that holds for your data is an empirical question, and everything below that sounds like a result comes from NVIDIA. We cover how the model works, the benchmark claims, how to try it, and the limits NVIDIA lists. Related models we have covered include Google's TabFM zero-shot tabular model and TimesFM 3.

TL;DR: Kumo Relational in one table

How it works

Most tabular foundation models take one flat table. Real business data is relational: users link to orders link to products, over time. Flattening it into one row means hand-written aggregates such as average order value over 30 days, which loses structure and takes human effort. Kumo Relational works on the database as it is, respecting tables, foreign keys and timestamps.

It is pre-trained once, on synthetic relational databases, and adapts to each task through in-context learning. Each context example pairs a local subgraph around an entity at a point in time with its known outcome, such as "this user churned." For prediction, three things must happen: understand values within each table, relate records across tables, and relate context examples to the entity being predicted.

• Automatic context generation. Tasks are written in PQL. For temporal tasks the system replays historical database states, samples subgraphs up to an anchor timestamp and computes targets from later events while showing the model only earlier data, which prevents leakage.
• Reasoning within tables. A lightweight network alternates column attention and row attention per table.
• Reasoning across tables. A larger network spreads row embeddings across primary-key and foreign-key links with graph attention, interleaved with cross-sample attention over context examples. Working on row embeddings, not every cell, avoids quadratic cost.

Synthetic pre-training

Real relational databases are rarely public, so the model learned from generated ones. The generator builds on PluRel (ICML 2026), whose authors include Kumo team members: a schema, foreign-key links that cluster as in real data, and column values from structural causal models with temporal trends and cross-table dependencies. NVIDIA says pre-training loss follows a power law as synthetic databases are added, with gains carrying over to real databases, citing the PluRel paper.

The benchmark claims

NVIDIA's evaluation covers 41 benchmarks across 15 databases in e-commerce, medical, enterprise, social and academic domains. Reported results:

• Beats the strongest supervised models in classification and regression, including relational deep learning models and expert-engineered tabular ensembles.
• On RelBench V1 classification, nearly 4 AUROC points above gradient-boosted trees on expert-engineered features on average.
• On SAP SALT, 7 MRR points above XGBoost on engineered features out of the box and 13 after fine-tuning; 8% MRR above large AutoGluon ensembles and about 25% above recent tabular foundation models, with fine-tuning extending the AutoGluon lead to 16%.
• Robustness: works with as little as 0.2% of training data as context, stays stable when up to 75% of foreign-key links are removed, and degrades little with many noisy columns.
• On the RelArena-alpha leaderboard it sits on the accuracy and efficiency Pareto front: about 17 seconds per 1,000 samples at Elo 1,842, versus the top entry, rt-plurel, at Elo 1,878 but roughly 430 times slower.

Read these as vendor results: NVIDIA's own paper and blog, selected benchmarks, no independent replication yet. The comparisons to "expert-engineered" XGBoost depend on how good those features were.

How to try it

The model ships in NVIDIA's open-source, GPU-native structured-data-models library, which downloads weights from Hugging Face on first use:

# pip install structured-data-models
import sdm

model = sdm.models.KumoRelational(device="cuda")
pred = model(
    x_context=..., y_context=...,
    x_query=...,
    related_context_tables=..., related_query_tables=...,
)

You can instead deploy it as an NVIDIA NIM and use the structured-data-models-client, writing the task in PQL:

query = sdm_client.PredictiveQuery(
    "PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id",
    {"users": ..., "orders": ...},
)

Quickstart notebooks for RelBench and SAP SALT pipelines are in the library and client repositories, with a Databricks example. Our advice: start with one focused query over a few relevant tables, compare against your current pipeline on a time-based holdout, and only then widen the graph.

A plain-language example

Say you run a subscription service with three tables: users, orders and support tickets. You want to know which users will place no order in the next 30 days. The traditional route is to build features by hand, such as orders in the last 90 days, average basket size, number of tickets, days since last login, then train and tune a gradient-boosted model, and repeat for every new question.

With a relational foundation model, you write the question in PQL and point it at the tables. The system picks past moments in time, looks at each user's neighborhood in the database as it stood then, and records what actually happened in the next 30 days. Those thousands of solved examples become the model's context. For a current user it looks at their neighborhood the same way and answers by analogy with the examples. No new weights are trained, so a second question, say predicting ticket volume, is another query.

The risks are the ones data scientists already know. Time handling decides whether results are honest: if context examples leak future information, accuracy looks great in testing and collapses in production. Class imbalance and rare events still need thought. And when the question depends on information outside the database, such as a competitor's promotion, no model can recover it.

Evaluating it fairly on your own data

1. Split by time. Train and context from earlier periods only, then evaluate on a later window, mirroring how predictions will be used.
2. Beat your real baseline. Compare against your production pipeline with its actual features, not a toy model.
3. Measure the cost. Record latency per thousand predictions and GPU time, since the leaderboard figure is NVIDIA's setup.
4. Test sparse context. Try small context sets, as NVIDIA says the model holds up with 0.2% of the training data, and see whether that holds for you.
5. Check stability. Re-run with noisy columns or missing links to see how predictions move.

Limits NVIDIA states

Kumo Relational works best on data with meaningful relationships and temporal dynamics. On tasks with very large training sets, task-specific supervised models may still beat in-context prediction, which used at most 10,000 context examples; fine-tuning is meant for that case. Predictive signals must be reachable within a limited number of hops. Also note the weights license is OpenMDW, not Apache, so read it before commercial use.

Why it matters for builders

If the claims hold on your data, the economics change: a new prediction becomes a query rather than a project, and agents can call PQL to ask what is likely to happen next. NVIDIA positions this as agents that can anticipate, not only read and write. A sibling release, Kumo Forecast, applies similar ideas to time series. The practical caution is the usual one for foundation models: verify on your own temporal split, watch for leakage in how you build context, and keep a baseline.

What we could not check

We did not run the model or reproduce any benchmark; every number here is from NVIDIA's blog and paper. We also did not read the OpenMDW License text, so confirm its terms for commercial use. The RelArena-alpha comparison is a leaderboard NVIDIA cites, and inference time depends on hardware and batch settings that the post summarizes only briefly. Independent replication, particularly on proprietary enterprise schemas that look different from public benchmarks, will be the real test.

What people are asking

Does this replace XGBoost? NVIDIA argues it can as a drop-in on relational tasks. Whether it does for you depends on your data and the strength of your current features.

Do I need to train anything? Not for the base model; you provide context examples and tables. Fine-tuning is optional.

Is it tied to NVIDIA hardware? The library is described as GPU-native, and the NIM route is NVIDIA's serving product.

Related reading

• Google TabFM zero-shot tabular foundation model
• Google TimesFM 3 multivariate forecasting
• Google TimesFM 2.5
• GTC Berlin 2026 keynote recap
• Neuralink pretraining a BCI foundation model
• What are embeddings and vector search?

Results are from NVIDIA's October 21, 2026 post and paper and are vendor-reported.