Skip to navigation

Relational Deep Learning

View as Markdown

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.

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

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.

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.

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.

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.

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.

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, an open-source benchmark suite with standardized datasets, task definitions, data loaders, and evaluation protocols for ML on relational databases.

DatabaseDomainTablesRowsColumnsTasks
rel-amazonE-commerce315.0M157
rel-avitoE-commerce820.7M424
rel-eventSocial541.3M1283
rel-hmE-commerce316.7M373
rel-stackSocial74.2M525
rel-trialMedical155.4M1405
rel-f1Sports974K673

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

DatabaseTaskLightGBMRDL (GNN)
rel-amazonuser-churn52.2270.42
rel-amazonitem-churn62.5482.81
rel-avitouser-visits53.0566.20
rel-avitouser-clicks53.6065.90
rel-eventuser-repeat53.0576.89
rel-eventuser-ignore79.9381.62
rel-f1driver-dnf68.8672.62
rel-f1driver-top373.9375.54
rel-hmuser-churn55.2169.88
rel-stackuser-engagement63.3990.59
rel-stackuser-badge63.4388.86
rel-trialstudy-outcome70.0968.60
Average62.4475.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

DatabaseTaskLightGBMGraphSAGENBFNet
rel-amazonuser-item-purchase0.160.740.10
rel-amazonuser-item-rate0.170.870.12
rel-amazonuser-item-review0.090.470.09
rel-avitouser-ad-visit0.060.023.66
rel-hmuser-item-purchase0.380.802.81
rel-stackuser-post-comment0.040.1112.72
rel-stackpost-post-related2.000.0710.83
rel-trialcond-sponsor-run4.822.8911.36
rel-trialsite-sponsor-run8.4010.7019.00
Average1.791.856.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

MetricLightGBM with manual featuresRDL (GNN)
Time per task12.3 hoursAbout 30 minutes
Lines of code878 (SD: 77)56
Feature engineeringManual, 50-100 featuresNone, end-to-end
Temporal handlingManual SQL logicAutomatic, 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, 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.