NVIDIA Kumo Relational: Foundation Models Finally Meet Your Database

NVIDIA Kumo Relational: Foundation Models Finally Meet Your Database

Foundation models rewrote the playbook for language and vision. We went from task-specific NLP pipelines with tokenizers and n-grams to general-purpose LLMs that just work. Now the same shift is happening to structured data, and I think it’s going to be messy, important, and surprisingly underrated.

NVIDIA just released Kumo Relational, a pre-trained foundation model that makes predictions directly on relational databases without feature engineering, without task-specific training, and without flattening your schema into a single table. You connect a database, write a simple query describing what to predict, and get predictions in one forward pass. That simplicity matters more than the benchmark wins, though the benchmarks are genuinely impressive.

Why This Breaks the Old Workflow

If you’ve built production ML systems, you know the drill. Someone asks for a churn prediction model. You spend weeks flattening relational data: aggregating user behavior into “average order value in the last 30 days,” computing “customer lifetime value,” rolling up transaction counts. Each aggregation is a guess about what signal matters. You lose fine-grained structure. You hand-engineer features. You train a model per task. You deploy XGBoost or a gradient-boosted ensemble. It works, but it’s expensive.

Kumo Relational skips most of that. It operates directly on your database schema, respects foreign keys and timestamps, and uses in-context learning to gather up to 10,000 historical examples as context at inference time. Think of it like prompt engineering for your database: instead of “write me a poem,” you’re saying “predict churn for this user based on their transaction history and product interactions.” The model figures out what matters.

On RelBench benchmarks, it beats expert-engineered XGBoost pipelines by nearly 4 AUROC points in classification. On SAP’s enterprise benchmark, it surpasses large AutoGluon ensembles by 8% in mean reciprocal rank. These aren’t marginal wins. These are the kinds of gains that justify a migration.

The Architectural Clarity

What impressed me most is how thoughtfully the system is designed. It does three things:

First, it reasons within tables. A lightweight network alternates column attention (relating values in a column) and row attention (relating features in a row), learning which columns matter and filtering noise early.

Second, it reasons across tables via graph attention over primary-key/foreign-key relationships. This is where the relational magic happens: linking a user’s profile to their transaction history to their product interactions.

Third, it does cross-sample attention across context examples. The model learns to compare the entity you’re predicting against other similar entities with known outcomes.

Crucially, the design avoids quadratic cost by working on row embeddings rather than cell-by-cell reasoning. This lets it scale to databases with 500 billion rows. The system also handles temporal leakage correctly: it replays historical database states, samples subgraphs up to an anchor timestamp, and only computes targets from events after that point.

What This Means for You

I keep coming back to one number: 430x faster than the highest-scoring alternative on RelArena-α while matching its accuracy. Speed matters for deployment. It matters for iteration. It matters for opening up prediction as a feature in products that were too data-intensive to tackle before.

For ML teams, this is a potential shift from “predictive modeling as a project” to “predictive modeling as a query.” A new use case doesn’t require spinning up a new pipeline. You write a Predictive Query Language (PQL) statement, the model gathers context, and you get results. That’s not just faster to build; it’s faster to experiment with.

For data engineers and platform teams, it’s a chance to move machine learning infrastructure left. Instead of feature engineering happening upstream, the model pulls what it needs directly from the database schema. That changes how you think about data pipelines.

The model is pre-trained on synthetic relational data (generated to reflect real-world schemas with PluRel), available in NVIDIA’s GPU-native structured-data-models library, and deployable as an NVIDIA NIM. Code is Apache 2.0. Model weights are under OpenMDW. You can load it in a notebook or run it as a service.

Where It Struggles

Kumo Relational performs best on data with meaningful relationships and temporal dynamics. If your signal is reachable in 2-3 hops across your schema, this will shine. On tasks where supervised models have massive training sets and the predictive signal is local and static, task-specific models might still edge it out slightly.

Fine-tuning is available for cases where accuracy demands it, but that reintroduces some of the overhead you were trying to avoid. Start focused with a few relevant tables and expand the graph as needed.

The Bigger Picture

What matters here isn’t just that Kumo Relational beats XGBoost on benchmarks. It’s that foundation models are collapsing the complexity tax for a new domain. We’re watching the same playbook unfold: the same three reasons LLMs displaced task-specific NLP (better accuracy, simpler production, flexible enough for agents) are now driving adoption in structured data.

Agents that can reason about relational data aren’t hypothetical anymore. They’re going to ask questions like “which customers are at risk of churn based on their product usage patterns?” and act on predictions in real time. That capability changes the kinds of systems you can build.

The question isn’t whether foundation models will replace your production ML pipelines for structured data. It’s how quickly you want to migrate, and whether you’re ready to rethink what predictions as a feature can unlock when they’re cheap and fast to generate.

Read Next