> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server.

# Relational Deep Learning

> How relational deep learning represents databases as temporal heterogeneous graphs and learns directly from their structure

Relational Deep Learning (RDL) treats a relational database as the temporal heterogeneous graph it already describes.
Instead of flattening tables and manually engineering features, RDL uses graph neural networks (GNNs) to learn from rows, foreign-key relationships, and time.

> **Info**
>
> **Source title:** Understanding Relational Deep Learning\
>
> **Originally published:** July 2024\
>
> **Venue:** ICML 2024\
>
> **Authors:** Matthias Fey, Weihua Hu, Kexin Huang, Jan Eric Lenssen, Rishabh Ranjan, Joshua Robinson, Rex Ying, Jiaxuan You, and Jure Leskovec\
>
> **Paper:** [Relational Deep Learning](https://arxiv.org/abs/2312.04615)

## The problem: ML on relational data

Much high-value enterprise data lives in relational databases: customer tables connect to transactions, products, categories, and other entities through primary-foreign key relationships.
A typical enterprise database has 10 to 50 interconnected tables and can contain billions of rows.

Conventional ML does not operate directly on that structure.
For each prediction task, practitioners join tables with SQL, compute aggregate features, flatten the result to one table, and train a model.
This feature-engineering workflow dominates the time, cost, and failure modes of enterprise ML.

The paper reports that a data scientist with a Stanford CS master's degree and five years of industry experience needed an average of 12.3 hours and 878 lines of code, with a standard deviation of 77 lines, to create one relational prediction task.
Each new task restarts the workflow, with different joins and aggregations for churn, fraud, recommendations, or lifetime value.

> **Tip**
>
> The limitation of feature engineering is not only speed.
> A manually designed feature set covers only a small part of the combinatorial space of multi-table, multi-hop, and time-windowed patterns.

## Why flat tables fail

![Comparison of traditional flat-table ML and relational deep learning, including each approach's benefits and limitations.](/sdgm/_fern-files/nvidia-sdgm.docs.buildwithfern.com/46c9f9838394ccdbc2ac8e8c55326f213198ba4fb82edbe36fe520dccd561adb/img/research/rdl-approach-comparison.svg)

Flattening relational data systematically discards information that can carry predictive signal:

* **Multi-hop relationships:** A customer's behavior can depend on products, categories, and other customers connected across several table hops.
* **Temporal sequences:** A count of five orders does not retain whether those orders were clustered early, spread evenly, or accelerating in value.
* **Graph topology:** Fraud rings, supply-chain cascades, and communities are patterns in the shape of a network rather than in individual row attributes.
* **Combinatorial interactions:** Humans cannot enumerate all useful combinations across related tables, time windows, and neighborhoods.

> **Note**
>
> **Analogy:** Flattening a relational database is like summarizing a social network with each person's follower count and average post frequency.
> The summary preserves attributes but loses who connects to whom, community structure, and temporal behavior.

Across seven databases and 30 tasks, the paper finds that automated approaches operating on the full relational structure identify patterns that manual feature engineering misses.

## The RDL paradigm shift

RDL adapts the algorithm to the database rather than flattening the database to fit the algorithm.
The conversion is direct:

* Each table **row** becomes a graph **node**.
* Each primary-foreign key relationship becomes an **edge**.
* Column values become **node features**.
* Row timestamps define temporal ordering and enforce causal visibility.

The result is a temporal heterogeneous graph.
It is temporal because a prediction at time *t* must only use information available before *t*, and heterogeneous because tables and relationships represent different types of nodes and edges.

## How RDL works: GNNs on databases

![Four-stage relational deep learning pipeline: convert the database to a graph, sample a temporally valid subgraph, apply GNN message passing, and use a prediction head.](/sdgm/_fern-files/nvidia-sdgm.docs.buildwithfern.com/8e968550be31f165fb4ef8c96a9cca80c080878337c051a6a5a8330e7c7fe95e/img/research/rdl-pipeline.svg)

Once the database is a temporal heterogeneous graph, RDL applies a GNN, GraphSAGE in the paper's baseline, to learn node representations through message passing.

### Message passing

In each round, a node collects messages from neighboring rows, transforms and aggregates them, and updates its representation.
After *K* rounds, an embedding contains information from the node's *K*-hop neighborhood.

For an e-commerce database with `customers`, `transactions`, and `products`, two rounds can encode a customer's own attributes, transaction history, and product attributes through `customer -> transaction -> product`.
Three rounds can additionally capture patterns among other customers who bought the same products.

### Temporal and heterogeneous structure

For a prediction at time *t*, RDL filters edges and sampled subgraphs to data from before *t*.
This prevents future data leakage and retains temporal dynamics such as recency, seasonality, and acceleration.
Different table and relationship types use type-aware transformations.

> **Note**
>
> **Analogy:** Message passing is a database query that writes itself.
> Rather than manually specifying joins and `GROUP BY` aggregates, the model learns what to collect from neighboring tables, how to weight it, and how to combine it.

## RelBench: a benchmark for relational deep learning

The paper introduces [RelBench](https://relbench.stanford.edu), an open-source benchmark suite with standardized datasets, task definitions, data loaders, and evaluation protocols for ML on relational databases.

| Database   | Domain     | Tables |  Rows | Columns | Tasks |
| ---------- | ---------- | -----: | ----: | ------: | ----: |
| rel-amazon | E-commerce |      3 | 15.0M |      15 |     7 |
| rel-avito  | E-commerce |      8 | 20.7M |      42 |     4 |
| rel-event  | Social     |      5 | 41.3M |     128 |     3 |
| rel-hm     | E-commerce |      3 | 16.7M |      37 |     3 |
| rel-stack  | Social     |      7 |  4.2M |      52 |     5 |
| rel-trial  | Medical    |     15 |  5.4M |     140 |     5 |
| rel-f1     | Sports     |      9 |   74K |      67 |     3 |

RelBench standardizes temporal train, validation, and test splits; precise task definitions; data loading and graph conversion; and evaluation metrics.
It covers node classification, node regression, and link prediction, evaluated with AUROC, MAE, and MAP\@K as appropriate.
The complete RDL pipeline in the RelBench Python package and PyTorch Geometric requires approximately 56 lines of code.

## Benchmark results

The paper compares manual-feature LightGBM with an RDL GraphSAGE baseline on classification tasks.
For recommendation tasks, it additionally compares GraphSAGE and the link-prediction GNN NBFNet.

### Classification results - AUROC, higher is better

| Database    | Task            |  LightGBM | RDL (GNN) |
| ----------- | --------------- | --------: | --------: |
| rel-amazon  | user-churn      |     52.22 |     70.42 |
| rel-amazon  | item-churn      |     62.54 |     82.81 |
| rel-avito   | user-visits     |     53.05 |     66.20 |
| rel-avito   | user-clicks     |     53.60 |     65.90 |
| rel-event   | user-repeat     |     53.05 |     76.89 |
| rel-event   | user-ignore     |     79.93 |     81.62 |
| rel-f1      | driver-dnf      |     68.86 |     72.62 |
| rel-f1      | driver-top3     |     73.93 |     75.54 |
| rel-hm      | user-churn      |     55.21 |     69.88 |
| rel-stack   | user-engagement |     63.39 |     90.59 |
| rel-stack   | user-badge      |     63.43 |     88.86 |
| rel-trial   | study-outcome   |     70.09 |     68.60 |
| **Average** |                 | **62.44** | **75.83** |

RDL outperforms LightGBM on 11 of 12 classification tasks, averaging 75.83 AUROC compared with 62.44, a 21% relative improvement.
The strongest gains occur on relationally rich tasks, including `rel-stack` user engagement at 90.59 versus 63.39.

### Recommendation results - MAP\@K, higher is better

| Database    | Task               | LightGBM | GraphSAGE |   NBFNet |
| ----------- | ------------------ | -------: | --------: | -------: |
| rel-amazon  | user-item-purchase |     0.16 |      0.74 |     0.10 |
| rel-amazon  | user-item-rate     |     0.17 |      0.87 |     0.12 |
| rel-amazon  | user-item-review   |     0.09 |      0.47 |     0.09 |
| rel-avito   | user-ad-visit      |     0.06 |      0.02 |     3.66 |
| rel-hm      | user-item-purchase |     0.38 |      0.80 |     2.81 |
| rel-stack   | user-post-comment  |     0.04 |      0.11 |    12.72 |
| rel-stack   | post-post-related  |     2.00 |      0.07 |    10.83 |
| rel-trial   | cond-sponsor-run   |     4.82 |      2.89 |    11.36 |
| rel-trial   | site-sponsor-run   |     8.40 |     10.70 |    19.00 |
| **Average** |                    | **1.79** |  **1.85** | **6.74** |

NBFNet has the strongest overall recommendation result, averaging 6.74 MAP\@K versus 1.79 for LightGBM.
GraphSAGE is strongest on the `rel-amazon` tasks, where collaborative-filtering patterns are especially useful.

### Development cost

| Metric              | LightGBM with manual features | RDL (GNN)              |
| ------------------- | ----------------------------- | ---------------------- |
| Time per task       | 12.3 hours                    | About 30 minutes       |
| Lines of code       | 878 (SD: 77)                  | 56                     |
| Feature engineering | Manual, 50-100 features       | None, end-to-end       |
| Temporal handling   | Manual SQL logic              | Automatic, graph-based |

RDL does not win every task: LightGBM slightly leads on `rel-trial` study outcome.
The reported pattern is that RDL's advantage grows with multi-hop structure, temporal dynamics, and graph topology.

## Concrete RelBench examples

### Stack Exchange: user engagement

The `rel-stack` database contains seven tables, including `users`, `posts`, `comments`, `votes`, `tags`, `postLinks`, and `badges`.
An RDL GNN can traverse paths such as `users -> posts -> tags` and `users -> posts -> votes -> voters` to capture topic and community dynamics that simple post counts and average scores do not retain.
The paper reports 90.59 AUROC for RDL versus 63.39 for LightGBM.

### Formula 1: race outcomes

The `rel-f1` database links drivers, results, races, circuits, constructors, qualifying sessions, lap times, pit stops, and standings.
RDL can learn multi-hop patterns involving circuit characteristics, constructor reliability, pit-stop strategy, and trends during a season.
On the driver-top3 task, RDL reaches 75.54 AUROC versus 73.93 for LightGBM.

### Amazon: recommendations

The `rel-amazon` database connects products, reviews, and ratings.
For user-item purchase prediction, the graph captures collaborative filtering, product similarity, and temporal behavior simultaneously.
GraphSAGE reaches 0.74 MAP\@K versus 0.16 for LightGBM, while user-item rating reaches 0.87 versus 0.17.

## Practical implications and what comes next

For practitioners, RDL moves feature engineering from the default approach to one option among others, while making temporal correctness part of the graph-processing workflow.
For enterprise teams, the reduction from 12.3 hours to roughly 30 minutes per task can increase task throughput and reduce dependency on hand-maintained feature stores.

RDL still trains a GNN separately for each task and database.
This result motivates relational foundation models such as [KumoRFM](/research/kumorfm-paper), which retain the relational graph representation while adding schema-agnostic encoding, graph-transformer attention, and in-context learning for zero-shot generalization.

Open directions include scaling to billion-row databases, handling more complex schemas, and integrating relational graph learning with data warehouses and existing ML infrastructure.