Why Flattening Relational Data Kills ML Accuracy

Every enterprise database is relational. Customers link to orders. Orders link to products. Products link to reviews. Reviews link back to other customers. The data lives in 5, 10, sometimes 50 interconnected tables with foreign keys, timestamps, and hierarchical relationships.

And every ML tool - XGBoost, LightGBM, random forests, neural networks, AutoML platforms, even the newest tabular foundation models - requires you to collapse all of that structure into a single flat table before it can make a prediction.

This flattening step is so ubiquitous that most data scientists do not question it. It is just "how ML works." You write SQL joins, compute aggregations, build a feature table with one row per entity, and feed it to a model. The entire field of feature engineering exists to make this flattening step less lossy.

But flattening is inherently lossy. And the signal it destroys is precisely the signal that separates good predictions from great ones.

The headline result: SAP SALT benchmark

The SAP SALT benchmark is an enterprise-grade evaluation where real business analysts and data scientists attempt prediction tasks on SAP enterprise data. It measures how accurately different approaches predict real business outcomes on production-quality enterprise databases with multiple related tables.

KumoRFM scores 91% where PhD-level data scientists with weeks of feature engineering and hand-tuned XGBoost score 75%. The 16 percentage point gap is the value of reading relational data natively instead of flattening it into a single table.

What flattening destroys

When you collapse a relational database into a flat table, you lose at least six categories of predictive signal that cannot be recovered by any downstream model, no matter how sophisticated.

Concrete example: Lead scoring

Consider Lead L-302 in a B2B CRM. The relational database contains rich, multi-table context about this lead:

• 4 contacts from 3 departments are active on the account - a multi-threaded buying committee, which is the strongest predictor of enterprise deal closure.
• Content progression: Blog → Case study → API docs → Demo request. This is a textbook buying journey from awareness to evaluation.
• Similar account closed $210K last quarter. The account-similarity signal comes from matching company attributes and engagement patterns across the opportunities table.
• Company raised Series B 30 days ago. Firmographic momentum from the accounts table indicates budget availability.

A flat-table model sees: emails_opened=4, pages_viewed=22, company_size=200. It has no way to know that those 4 emails came from 3 different departments, that the 22 page views followed a specific buying-stage progression, or that a similar account just closed a $210K deal. All of the signal that makes this a high-value lead is invisible.

Concrete example: Fraud detection

Account A sends $500 to Account B. Account B sends $480 to Account C. Account C sends $460 to Account D. Account D sends $440 back to Account A. Each individual transaction looks perfectly normal - a modest transfer between two accounts.

But the pattern is a fraud ring: A → B → C → D → A. Money is cycling through four accounts, with small amounts skimmed at each step. This circular flow is a classic money laundering pattern, and it is only visible when you can see the graph structure of transactions.

When you flatten the transaction data into a single row per transaction, each row contains: sender_id, receiver_id, amount, timestamp. There is no column for "this transaction is part of a four-node cycle." The ring is invisible. No amount of feature engineering on a single transaction row can recover the circular topology - because the pattern exists across four rows, not within one.

Concrete example: Churn prediction

Member Bob visits his gym 4 times per week on average. Over the last 6 weeks, his visit frequency dropped 68% - from 4 visits to 1.3. That alone is a churn signal. But the relational data reveals more:

• Bob's workout buddies are also churning. Two of his three regular workout partners have cancelled in the last month. Social churn is contagious - when your peers leave, you are far more likely to leave.
• Bob downgraded his plan from Premium to Basic last billing cycle, reducing his monthly payment from $79 to $29. This is a leading indicator of full cancellation.
• Bob stopped attending group classes. His class attendance went from 3 per week to 0. Group class members have 2.3x higher retention, so losing this engagement channel is significant.

When flattened: visit_frequency=1.3, plan_type=Basic, monthly_spend=$29. The social churn signal - the fact that Bob's friends are leaving - disappears entirely. The peer behavior pattern exists in the relationships between members, not in any single member's row.

The accuracy gap: RelBench results

The destruction is not theoretical. The RelBench benchmark (7 databases, 30 tasks, 103 million rows) measures exactly how much signal is lost when you flatten relational data versus processing it in its native structure.

AUROC (Area Under the Receiver Operating Characteristic curve) measures how well a model distinguishes between positive and negative outcomes. An AUROC of 50 means random guessing, 100 means perfect prediction. Moving from 65 to 77 AUROC means the model correctly ranks a true positive above a true negative 77% of the time instead of 65%.

The gap is not uniform. Tasks that depend heavily on multi-hop relationships, temporal sequences, and graph structure show the largest gaps. Tasks that are well-served by simple aggregations (count, sum, mean) show smaller gaps. But in no case does the flat approach match the relational approach.

The feature space math

The accuracy gap has a mathematical explanation. Consider a modest enterprise database with 5 tables and 50 columns per table.

This is not a criticism of data scientists. No human can enumerate 2.2 million features and test them for predictive value. The combinatorial space is too large. Data scientists use domain knowledge to build the 50-200 features they believe matter most. But domain knowledge is biased toward obvious signals and misses subtle multi-hop interactions.

A foundation model that reads the relational structure directly does not enumerate features at all. It learns a continuous representation of the entire relational neighborhood around each entity, implicitly capturing all of the patterns that exist in the data - including the 83-96% of the feature space that human engineers never explore.

Why TabPFN and Fundamental do not solve this

TabPFN (from the University of Freiburg) and Fundamental are tabular foundation models - pre-trained models designed for tabular data. They represent genuine advances in model architecture. On single-table benchmarks, they often match or beat well-tuned XGBoost and LightGBM ensembles.

But they are still tabular models. Their input is a flat table with one row per entity and a fixed number of columns. The flattening step - the SQL joins, the aggregations, the lossy collapse of relational structure into scalar features - happens before TabPFN or Fundamental ever sees the data.

Think of it this way: TabPFN is a better lens for looking at a photograph. KumoRFM is a better camera that captures more of the scene. No amount of lens improvement can recover detail that was never captured in the photograph.

How KumoRFM avoids flattening

KumoRFM takes a fundamentally different approach. Instead of requiring a flat table, it represents the entire relational database as a temporal heterogeneous graph:

• Each row in each table becomes a node. A customer row is a customer node. An order row is an order node. A product row is a product node.
• Each foreign key becomes an edge. The customer_id foreign key in the orders table creates an edge from each order node to its customer node. The product_id foreign key creates an edge from each order to its product.
• Timestamps are preserved. Every node and edge carries its temporal information. The model can distinguish between a customer who placed 10 orders last week and a customer who placed 10 orders over 3 years.
• A graph transformer processes the full structure. Information propagates through the graph via message passing. After 3 layers, each node has aggregated context from entities up to 3 hops away - capturing exactly the multi-hop patterns that flattening destroys.

PREDICT churn_90d
FOR EACH members.member_id
WHERE members.status = 'active'

The bottom line: flattening is the bottleneck

The ML industry has spent a decade building better models for flat tables: XGBoost, LightGBM, CatBoost, TabPFN, Fundamental, AutoML ensembles. Each new model squeezes another 1-3 AUROC points out of the same flat feature table. Meanwhile, the gap between flat features and full relational data is 14-19 points.

The bottleneck was never the model. It was always the data representation. Flattening a relational database into a single table destroys the very patterns that differentiate accurate predictions from mediocre ones: multi-hop relationships, temporal sequences, graph topology, and cross-table interactions.

The solution is not better feature engineering. The solution is not trying harder to flatten without losing signal. The solution is eliminating the flattening step entirely - reading relational data in its native structure, the way it was designed to be stored.

That is what relational foundation models do. And the 14-19 AUROC point improvement is the signal that flattening was destroying all along.