> 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.

# PluRel: Synthetic Relational Data

> How synthetic relational databases make scaling-law research possible for relational foundation models

PluRel is a framework for generating synthetic relational databases from scratch.
It makes it possible to study how relational foundation models scale with both the diversity and volume of their pretraining data.

**Source title:** Understanding PluRel: How Synthetic Data Unlocks Scaling Laws for Relational Foundation Models\

**Published:** February 2026\

**Authors:** Vignesh Kothapalli, Rishabh Ranjan, Valter Hudovernik, Vijay Prakash Dwivedi, Johannes Hoffart, Carlos Guestrin, and Jure Leskovec\

**Paper:** [arXiv:2602.04029](https://arxiv.org/pdf/2602.04029)

## The data problem

Scaling laws are one of the most important discoveries in modern AI.
For large language models, more data and more compute predictably produce better models.
GPT-3 was trained on 300 billion tokens, while GPT-4 was trained on trillions.

Relational foundation models (RFMs) such as KumoRFM should follow the same pattern.
They learn from interconnected tables that power enterprise systems, including customers, transactions, products, and accounts.
In theory, more diverse databases should produce models that generalize better to new schemas and tasks.

Real-world relational databases are almost never publicly available.
Enterprise data contains customer records, financial transactions, medical histories, supply-chain details, and other sensitive information.
Privacy laws, confidentiality, and regulatory requirements make large pretraining corpora difficult to assemble.

The RelBench benchmark contains only seven databases.
That scarcity has prevented researchers from determining whether scaling laws exist for RFMs, because it does not provide enough databases to vary data scale meaningfully.

**Analogy:** Studying RFM scaling with seven databases is like trying to discover language-model scaling laws with seven books.
You can train on them, but you cannot learn what happens with 1,000 or 10,000 books.

The bottleneck for relational foundation models is data, not architecture or compute.
PluRel addresses that bottleneck by generating diverse relational databases synthetically.

## Why existing methods are not enough

Synthetic tabular data is not new, but existing methods do not solve the relational-data problem.

### Single-table generators

Structural causal models (SCMs) can generate a single table while preserving column distributions, correlations, and causal relationships.
However, a relational database is not a collection of independent tables.
Primary-foreign-key relationships determine how rows connect and how information flows across tables.

Generating tables independently and then assigning random foreign keys destroys this structure.
The connectivity pattern determines locality at the table, row, and whole-database levels.

### GAN and diffusion generators

GAN-based methods such as conditional-TGAN and diffusion methods such as ClavaDDPM and Reldiff can model characteristics of a real database.
They require an existing database as input, however, so they generate variations rather than novel schemas from scratch.

### The multi-table challenge

Relational databases have structure at three levels simultaneously:

1. **Schema:** The tables, their relationships, and connection topology.
2. **Connectivity:** The specific row-to-row foreign-key links, including hierarchical clustering.
3. **Features:** Cell values with temporal patterns, cross-table correlations, and causal dependencies.

PluRel generates all three levels together.

## How PluRel works

PluRel generates complete relational databases in three stages.

![Three-stage PluRel pipeline: sample a schema DAG, create hierarchical foreign-key connectivity, then generate causal and temporal feature values.](https://fdr-prod-docs-files-public.s3.us-east-1.amazonaws.com/nvidia-sdgm.docs.buildwithfern.com/ffdb999303d94107c55a21e96fc73b71ebffef3f9c36c11c64b3ae505cd4db7d/img/research/plurel-generation-pipeline.svg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIA6KXJSKKNFOCF7G4B%2F20260920%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260920T164624Z&X-Amz-Expires=604800&X-Amz-Signature=69889b755dc529ebbe1dbfcfca835f1ab98b426895056a6ae5857c9818e0e5c8&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject)

### Stage 1: Schema generation

PluRel samples the database schema as a random directed acyclic graph (DAG).
Nodes represent tables and edges represent primary-foreign-key relationships.
It draws from graph families that model different real-world patterns:

* **Barabasi-Albert graphs** model hub tables with preferential connectivity, such as a central `users` table.
* **Reverse random-tree graphs** model strictly hierarchical schemas, such as organizational structures.
* **Watts-Strogatz graphs** model clustered table schemas with a few cross-references between modules.

Tables with outgoing edges are entity tables, such as users or products.
Tables without outgoing edges are activity tables, such as transactions or clicks.
Entity tables contain 500 to 1,000 rows and activity tables contain 2,000 to 5,000 rows; each table has 3 to 40 feature columns with sampled types.

### Stage 2: Foreign-key connectivity

Real databases show hierarchical clustering in foreign-key connectivity.
Some users have thousands of transactions while others have few, and related products can be purchased by overlapping customer groups.

PluRel uses a **Hierarchical Stochastic Block Model (HSBM)** for each connected table pair.
It partitions rows in both tables into hierarchical clusters, then samples links according to cluster membership.
Rows in matching blocks link with probability around 0.9, while rows in different blocks link with probability around 0.001 to 0.002.

**Analogy:** In a university database, engineering students mostly link to engineering departments rather than randomly to every department.
HSBM captures this preferential within-cluster connectivity.

### Stage 3: Feature generation

Each table receives an SCM whose nodes are feature columns and whose edges are causal relationships.
The SCM models:

* **Temporal patterns:** Activity-table features include trends, cycles, and bounded fluctuations instead of assuming independent, identically distributed rows.
* **Cross-table dependencies:** Child-table features depend on parent-table features through foreign-key links.
* **Type diversity:** Features are numeric or categorical, generated through continuous functions or softmax distributions over temporal functions.

The causal graphs are sampled from layered, Erdos-Renyi, Barabasi-Albert, random-tree, and reverse-random-tree families.
Each node value is computed by a randomly initialized MLP, producing a distinct non-trivial distribution for every synthetic database.

### Computational efficiency

PluRel is CPU-only and lightweight.
Generating a synthetic database takes roughly 14 to 17 seconds per table on a single thread, with peak memory below 1 GB even for an 80-table database.

| Tables | Latency (seconds) | Peak memory (GB) |
| ------ | ----------------: | ---------------: |
| 10     |        147.5 ± 66 |      0.45 ± 0.01 |
| 20     |       267.0 ± 129 |      0.55 ± 0.04 |
| 40     |       584.3 ± 252 |      0.77 ± 0.06 |
| 80     |     1,368.6 ± 950 |      0.91 ± 0.11 |

## Scaling laws for RFMs

With an effectively unlimited supply of synthetic databases, the paper studies two independent axes:

* **N, diversity:** Number of synthetic databases, from 8 to 1,024.
* **S, size:** Total pretraining tokens extracted from those databases, from 0.5 to 32 billion.

The experiments pretrain a 12-layer Relational Transformer (RT) using masked token prediction.
Each configuration trains from scratch on one Blackwell B200 GPU in roughly three hours and is evaluated on 100 held-out synthetic databases.

### The power laws

Validation loss follows power-law relationships on both axes:

* **Diversity scaling:** `L(N) = 0.07 · N^(-0.38) + 0.36`
* **Size scaling:** `L(S) = 0.025 · S^(-0.48) + 0.36`

Neither axis can be scaled independently.
At a fixed token budget, increasing diversity too far causes underfitting because the model sees each database too rarely.
At fixed diversity, increasing total size causes overfitting because the model memorizes a limited set of databases.
The optimal frontier scales N and S together, using separate power laws for each optimal frontier rather than a single joint law.

For RFMs, both more databases and more tokens from those databases are necessary.
The optimum is not obtained by maximizing either one alone.

## Transfer to real databases

The paper evaluates zero-shot performance on RelBench across six real-world databases and 18 tasks.
It compares three strategies:

1. **Real only:** Pretrain on RelBench with leave-one-database-out evaluation.
2. **Synthetic + real:** Pretrain on PluRel data, then continue pretraining on RelBench.
3. **Synthetic only:** Pretrain on PluRel data alone.

### Classification results (AUROC)

| Dataset    | Task        | Real only | Synthetic + real |     Gain | Synthetic only |
| ---------- | ----------- | --------: | ---------------: | -------: | -------------: |
| rel-amazon | user-churn  |      64.2 |             65.0 |     +0.8 |           64.4 |
| rel-hm     | user-churn  |      67.4 |             66.0 |     -1.4 |           63.7 |
| rel-stack  | user-badge  |      80.0 |             82.0 |     +2.0 |           81.4 |
| rel-stack  | user-engage |      78.9 |             86.2 |     +7.4 |           82.4 |
| rel-amazon | item-churn  |      67.6 |             72.5 |     +4.9 |           71.0 |
| rel-avito  | user-visits |      57.2 |             63.4 |     +6.2 |           63.5 |
| rel-avito  | user-clicks |      54.7 |             47.9 |     -6.8 |           45.9 |
| rel-trial  | study-out   |      54.4 |             51.8 |     -2.6 |           53.8 |
| rel-f1     | driver-dnf  |      80.7 |             81.0 |     +0.3 |           76.7 |
| rel-f1     | driver-top3 |      86.9 |             88.4 |     +1.5 |           82.6 |
| **Mean**   |             |  **69.2** |         **70.4** | **+1.2** |       **68.5** |

### Regression results (R²)

| Dataset    | Task       | Real only | Synthetic + real |     Gain | Synthetic only |
| ---------- | ---------- | --------: | ---------------: | -------: | -------------: |
| rel-hm     | item-sales |      16.0 |             20.0 |     +4.0 |            4.4 |
| rel-amazon | user-ltv   |      14.5 |             18.5 |     +4.0 |            9.8 |
| rel-amazon | item-ltv   |      35.3 |             40.5 |     +5.2 |           10.7 |
| rel-stack  | post-votes |      22.3 |             25.5 |     +3.2 |           15.7 |
| rel-trial  | site-succ  |      33.7 |             38.6 |     +5.0 |           38.3 |
| rel-trial  | study-adv  |       1.9 |              1.6 |     -0.3 |           -0.8 |
| rel-f1     | driver-pos |      54.3 |             55.5 |     +1.2 |           41.3 |
| rel-avito  | ad-ctr     |       3.1 |              4.9 |     +1.9 |            2.5 |
| **Mean**   |            |  **22.6** |         **25.7** | **+3.0** |       **15.2** |

Synthetic plus real pretraining has the strongest mean performance: a 1.2-point absolute AUROC gain in classification and a 3.0-point absolute R² gain in regression compared with real-only pretraining.
It outperforms real-only on seven of eight regression tasks.

Synthetic-only pretraining underperforms on most tasks.
Synthetic data provides broad relational patterns, but continued pretraining on real data aligns the model to real-world distributions.
The paper attributes some combined-strategy declines to PluRel's current lack of textual and column-semantic information.

## The Relational Transformer

PluRel is a data-generation framework, not a model architecture.
The evaluation model is a 12-layer Relational Transformer designed for relational data.

### Cell-level tokenization

The RT represents each cell as a `(value, column_name, table_name)` token triple.
Numeric, Boolean, and datetime cells receive type-specific normalization.
Text cells use a frozen text encoder, while column and table names use a pretrained sentence encoder so the model can use schema semantics.

### Relational attention

The RT uses structured attention masks:

* **Column attention:** Attends within a column to capture column-level statistics and cross-row patterns.
* **Feature attention:** Attends within a row and to foreign-key-linked parent rows.
* **Neighbor attention:** Attends to primary-foreign-key-linked child rows, analogous to GNN message passing.

Its masked token prediction objective masks random cells and predicts their values.
Numeric targets use Huber loss, while Boolean targets use cross-entropy loss.

PluRel's hierarchical connectivity and temporal patterns make its data useful for this architecture.
They give relational-attention layers patterns that can transfer, unlike random connectivity and independent features.

## Engineering improvements

The paper introduces Query-Key Normalization (QK-Norm) to stabilize RT pretraining across diverse synthetic databases and mixed cell types.
Applying RMSNorm to query and key vectors before attention dot products reduces the reported cross-seed AUROC difference from 10.5% to 2.2%.

QK-Norm also improves the real-only baseline.
The paper reports that removing it decreases mean AUROC by 3.1 points and mean R² by 3.7 points because of early overfitting, particularly on binary classification tasks.

## Limitations and next steps

PluRel currently has several limitations:

* It does not generate self-referencing foreign keys, such as a `posts.ParentID` reference to another row in `posts`.
* It uses generic feature names rather than schema semantics such as `price` or `age`.
* It generates numeric and categorical columns only, not text, images, geospatial data, JSON, or encrypted fields.

The paper identifies column semantics, multimodal data, semi-synthetic augmentation, and joint model-and-data scaling laws as future directions.
The framework and generated data are available in the [PluRel GitHub repository](https://github.com/snap-stanford/plurel).

## Further reading

* [PluRel paper](https://arxiv.org/abs/2602.04029)
* [PluRel on GitHub](https://github.com/snap-stanford/plurel)
* [KumoRFM overview](/rfm/overview)