Berlin Tech Meetup: The Future of Relational Foundation Models, Systems, and Real-World Applications

Register now:
PyG/Guide8 min read

Relational Foundation Models: Foundation Models Trained on Database Structure

GPT understands language. CLIP understands images. A relational foundation model understands relational databases: tables, foreign keys, timestamps, and the patterns hidden in multi-table enterprise data.

PyTorch Geometric

TL;DR

  • 1A relational foundation model (RFM) is pre-trained on relational database structure, understanding tables as node types, foreign keys as edges, and temporal dynamics of enterprise data.
  • 2RFMs convert any relational database into a heterogeneous temporal graph, then use graph transformers to learn from the full relational context across all tables.
  • 3KumoRFM achieves 76.71 AUROC zero-shot on RelBench (no training on target data), beating task-specific flat-table models at 62.44 that had full training access. Fine-tuned: 81.14.
  • 4The interface is one line of PQL: PREDICT churn FOR customers WITHIN 30 days. No feature engineering, no model selection, no training pipeline.
  • 5RFMs follow scaling laws: more pre-training data, more parameters, and more diverse databases yield predictably better transfer performance on new tasks.

A relational foundation model (RFM) is a foundation model specifically designed and pre-trained on relational database structure. It understands that enterprise data lives in tables connected by foreign keys, that each row is an entity with typed features, and that events happen in temporal order. This specialization allows RFMs to outperform both general-purpose ML models and generic graph foundation models on enterprise prediction tasks.

From databases to graphs

The first step in an RFM pipeline is converting the relational database into a heterogeneous temporal graph:

  • Tables become node types: Each table (customers, orders, products) is a distinct node type with its own feature space.
  • Rows become nodes: Each row in a table is a node. A 1M-row customer table produces 1M customer nodes.
  • Foreign keys become edges: Each foreign key relationship (order.customer_id references customers.id) produces edges connecting order nodes to customer nodes.
  • Timestamps become temporal ordering: Edges and nodes have timestamps that enable temporal sampling and time encoding.
database_to_graph.py
# Conceptual: relational database -> heterogeneous temporal graph
# KumoRFM does this automatically from your database schema

# Tables -> node types
graph.add_node_type('customer', features=['age', 'tenure', 'segment'])
graph.add_node_type('order', features=['amount', 'discount', 'channel'])
graph.add_node_type('product', features=['price', 'category', 'brand'])

# Foreign keys -> edge types
graph.add_edge_type('customer', 'placed', 'order',
                    timestamp_col='order_date')
graph.add_edge_type('order', 'contains', 'product')

# Result: heterogeneous temporal graph
# Nodes: 1M customers + 5M orders + 100K products
# Edges: 5M placed + 8M contains
# Each edge has a timestamp for temporal sampling

This conversion is automatic. The RFM reads the database schema and foreign key constraints to build the graph.

The architecture

An RFM uses a graph transformer architecture that is specifically designed for heterogeneous relational data:

  1. Type-specific encoders: Each node type gets its own input projection, handling different feature dimensions and types across tables.
  2. Relational graph transformer: Attention operates across node types, with relation-type-aware attention weights. The model learns that “customer placed order” and “order contains product” have different semantics.
  3. Temporal awareness: Time encodings and temporal sampling ensure the model respects causal ordering. No future information leaks into representations.
  4. Schema-agnostic design: The architecture handles arbitrary numbers of tables, columns, and relationships. A new database with a never-seen schema can be processed without architectural changes.

Pre-training at scale

RFMs are pre-trained on diverse relational databases using masked token prediction:

  • E-commerce databases: customer behavior, product interactions, purchase patterns
  • Financial databases: transactions, accounts, merchant networks
  • Healthcare databases: patients, visits, diagnoses, treatments
  • SaaS databases: users, sessions, features, subscriptions

The diversity of pre-training data is critical. Each database teaches the model different relational patterns, and the model learns to generalize across them. KumoRFM was pre-trained on 103 million rows across 7 diverse databases.

Zero-shot prediction with PQL

The user interface for an RFM is a single line of Predictive Query Language (PQL):

pql_examples.py
# Churn prediction
PREDICT churn FOR customers WITHIN 30 days

# Lifetime value
PREDICT SUM(orders.amount) FOR customers WITHIN 90 days

# Fraud detection
PREDICT is_fraud FOR transactions

# Product recommendation
PREDICT link(customer, product) FOR customers

One line per prediction task. No feature engineering, no model training, no ML pipeline. The RFM handles everything.

Results: RelBench benchmark

RelBench is the standard benchmark for relational deep learning, covering 7 databases and 30 prediction tasks:

  • Flat-table LightGBM: 62.44 AUROC (trained per task)
  • Task-specific GNN: 75.83 AUROC (trained per task)
  • KumoRFM zero-shot: 76.71 AUROC (no target training)
  • KumoRFM fine-tuned: 81.14 AUROC (minutes of adaptation)

The zero-shot RFM outperforms models that had full access to the training data. This is the strongest evidence that relational patterns transfer across databases.

Frequently asked questions

What is a relational foundation model?

A relational foundation model (RFM) is a foundation model specifically designed for relational database structure. It understands tables as node types, foreign keys as edges, and timestamps as temporal ordering. Unlike general graph foundation models, an RFM is optimized for the specific structure of enterprise databases.

How does a relational foundation model differ from a general graph foundation model?

A general graph foundation model handles arbitrary graphs (social, molecular, etc.). An RFM is specialized for relational databases: it understands table schemas, column semantics, foreign key relationships, and temporal dynamics of enterprise data. This specialization yields better performance on enterprise prediction tasks.

What can KumoRFM predict?

KumoRFM can predict any entity-level outcome described in natural language on any relational database: churn, fraud, lifetime value, demand, conversion, default risk, recommendations. You write one line of PQL (Predictive Query Language) and get predictions without training a custom model.

Learn more about graph ML

PyTorch Geometric is the open-source foundation for graph neural networks. Explore more layers, concepts, and production patterns.