Why GNNs Matter for Tabular Data

A brand-new account signs up, runs one small payment, and your fraud model shrugs. There’s nothing in the row to judge — no history, no pattern, blanks where the useful columns would be. To a single-table model, this account looks like every other new signup.

But it isn’t. The card it used was flagged on three other accounts last week, and the device traces back to a ring you’ve already caught. That signal exists. It’s just not in the account’s row — it’s in who the account is connected to.

A flat model can’t see connections. A graph neural network is built to.

What “message passing” actually does

The idea behind a graph neural network (GNN) is simple once you drop the jargon. Lay your data out as a graph: every record is a dot, every link between records is a line. Then each dot updates itself with a short summary of its neighbors — and repeats that a couple of times. Signal travels along the links. That’s message passing.

Back to the new account. Here’s what a tabular model sees — one flat row:

account	days_old	txns	flagged?
A99	0	1	?

Nothing to go on. Now the same account as part of the graph — it shares a card with three others:

A99 shares a card with	flagged?
X	yes
Y	yes
Z	yes

One round of message passing pulls “three flagged neighbors” into A99’s own representation. Same data, opposite conclusion. The row hid the answer; the connections carried it.

The model reads the graph your database already is

Here’s the part teams miss: you don’t have to build this graph. Your database already is one. Tables are kinds of nodes, rows are nodes, and every foreign key — the link that says “this order belongs to that customer” — is an edge. A relational database is a graph wearing a spreadsheet costume.

And the models that read it keep getting sharper. A 2025 architecture called RelGNN builds its message-passing paths straight from the foreign keys, no hand-designed routes, and beat a standard graph network on 17 of 30 benchmark tasks — up to 25% better on one. The trend is consistent: the closer a model hugs the real foreign-key structure, the more signal it finds.

Our read: the value was never the fancy model. It’s that the connections are the signal, and flattening deletes them. Keep the edges and you keep the answer.

When the graph matters most

The graph earns its keep whenever a record’s answer depends on the records around it:

Situation	Why the graph wins
Cold-start (new user, account, product)	Borrows signal from neighbors when the row itself is empty
Fraud rings, money flows	Multi-hop patterns a single join can’t express
Recommendation	”People like you bought…” lives in user → item → user paths

If your data is genuinely one table with no links worth following, you won’t need any of this — a plain model is simpler. The graph wins when the answer is in the neighbors.

Common questions

Do I have to build the graph myself?

No. Your foreign keys already define it — the model reads the links that are in your schema. There’s no graph theory on your end.

What's message passing, in one line?

Each record updates itself with a summary of its neighbors, a few times over, so signal travels along the connections.

Is this only useful for fraud and recommendations?

No — those are just the vivid cases. It helps anywhere an outcome leans on related records: churn, credit risk, demand, lead scoring.

So do GNNs replace XGBoost?

Not at all. On one clean table, XGBoost is great. The graph wins when the signal lives in the connections — see Tabular vs Relational ML: When Each Wins.

The bottom line

Flat models treat every row as an island. Most business data isn’t islands — it’s a web of customers, orders, devices, and payments, already wired together by foreign keys. Graph neural networks learn over that web instead of erasing it, which is why they keep finding signal that hand-built features miss. And you don’t have to become a graph expert to use it: Langsat reads your database as the graph it already is, and learns straight from the connections.

---

Sources: RelGNN (ICML 2025) and Relational Deep Learning (ICML 2024).