Tabular vs Relational ML: When Each Wins

Say you want to predict which customers are about to cancel. The clues are everywhere: the orders they placed, the support tickets they opened, how often they logged in last month. But none of that lives in one tidy place. It’s scattered across a dozen tables, wired together: a customer links to their orders, an order to its products, and so on.

To feed most machine learning, you first have to flatten all of that into a single row of summary numbers: total orders, days since last login, average ticket time. It works. It’s also where teams burn weeks, and quietly throw away half the story.

For a long time, that was just the job. Two recent shifts changed it.

The move everyone makes: flatten, then predict

Spreadsheet machine learning — call it tabular — wants one row per thing you’re predicting, and tools like XGBoost are brilliant at it. But real business data is relational: many tables, joined by foreign keys — the links that say “this order belongs to that customer.”

Here’s the same data both ways. First, how a database actually stores it — two linked tables:

customers

id	name
1	Ada
2	Ben

orders — each row’s customer points back to a customer; that link is the foreign key:

id	customer	amount
9	1	$42
8	1	$30
7	2	$12

To feed a tabular model, you flatten that into one row per customer, counting and summing by hand:

customer	orders	total
Ada	2	$72
Ben	1	$12

That summarizing is feature engineering: slow, fragile, and it throws the connections away.

Shift one: the table tools caught up

For years, simple tree models beat deep learning on a single table. That stopped being a rule. A newer model called TabPFN changed it — a “foundation model for tables,” pretrained once on about 100 million example tables (that’s the model’s training, not your data). You point it at your own table and it predicts in one shot, no training of your own. In one test it matched a heavily tuned setup that took four hours, in 2.8 seconds. The fine print: it’s built for small tables, a few thousand rows at most. So yes, deep learning caught up — in a narrow lane.

Shift two: relational deep learning reads the web

The bigger idea is to stop flattening altogether. Picture every record as a dot, every foreign key as a line — your database is already a web. A type of model called a graph neural network can learn straight over that web, starting from each row’s own columns. Nobody writes features by hand; the model learns which connections matter. This is relational deep learning.

Does it actually pay off? In a benchmark called RelBench, researchers pitted it against an experienced data scientist doing the traditional, hand-built version across 15 tasks. The model won on 11 of them — in about 30 minutes per task instead of 12 hours, with a fraction of the code. It didn’t just save time. It was more accurate.

Our read: that’s the real headline. Flattening was never free — it just hid its price inside weeks of someone’s careful, breakable work. Keep the connections, and that cost turns back into signal.

Tabular vs relational: which should you use?

Stay tabular when your data really is one table and it’s on the smaller side — a tuned tree is hard to beat and easy to ship. Go relational when the answer lives in the connections: many tables, behavior that unfolds over time, a schema too big to flatten by hand.

	Tabular	Relational
Data shape	One table	Many tables, foreign keys
Signal lives in	Columns	Relationships & history
Best when	Small, simple	Large, connected
Feature work	By hand	Learned by the model

Common questions

Is relational deep learning better than XGBoost?

On one clean table, no — trees or TabPFN are usually simpler and just as strong. On a multi-table database, the graph approach beat hand-built features on 11 of 15 benchmark tasks, so it’s often the better place to start.

Do I need a graph neural network for my data?

Only when there’s a web to learn from — links between tables. If you’ve been joining tables by hand to build features, that’s your sign.

Can I just use TabPFN on my database?

Not directly. It’s made for single tables of a few thousand rows, so you’d flatten first — which brings back the exact work relational models skip.

What is RelBench?

The public benchmark behind the numbers here — built to test deep learning directly on relational databases (Stanford, 2024).

The bottom line

Tabular tools got better, but mostly for small, simple data. The deeper change: we no longer have to destroy the shape of a database to learn from it. And you usually can’t tell up front which shape your problem is — so Langsat reads your database as it is and runs both, using the graph view when the links carry signal and a plain table model when they don’t.

---

Sources: RelBench (NeurIPS 2024) and TabPFN (Nature, 2025).