Everyone is calling everything a “foundation model for structured data” right now. Actual pre-trained models that generalize across datasets. AutoML platforms that train a new model for every task. Semantic data layers that just help LLMs query databases. Even BI dashboards are getting the label. Most comparisons get the categories wrong, and some of the most-cited overviews include models that were retired years ago or, in at least one case, do not actually exist.
This guide is opinionated. We cover every model that matters, call out what is real vs. marketing, and show published benchmarks where they exist. Where benchmarks do not exist, we say so.
Three categories, three different problems
The first thing to get right: these are not all solving the same problem. Mixing them together leads people to pick the wrong tool entirely.
foundation_model_categories_for_structured_data
| category | what_it_reads | what_it_predicts | examples | enterprise_use_cases |
|---|---|---|---|---|
| Tabular Foundation Models | Single flat table (one row per entity, one column per feature) | Classification, regression on flat tabular data | TabPFN (PriorLabs), NEXUS (Fundamental), NICL (Neuralk AI), TabICL, CARTE | Small-data predictions, rapid prototyping, single-table benchmarks |
| Relational Foundation Models | Multiple connected tables via foreign keys (5-50 tables) | Classification, regression, recommendation, ranking across relational data | KumoRFM 2.0 (Kumo.ai) | Churn, fraud, lead scoring, demand forecasting, recommendations - any task where signals span multiple tables |
| Time Series Foundation Models | Temporal sequences (timestamps + values) | Forecasting future values in a sequence | Chronos (Amazon), TimesFM (Google), Moirai (Salesforce), Moment (CMU) | Demand forecasting, capacity planning, price prediction, anomaly detection in temporal data |
Three categories, three different input structures, three different problem types. Most overviews lump them together, but the choice depends on your data structure: flat table, relational database, or time series.
Time series foundation models keep showing up in these comparisons, so let us be clear: Chronos (Amazon), TimesFM (Google), Moirai (Salesforce), and Moment (CMU) are real foundation models, but they forecast temporal sequences. They predict the next value in a time series. They do not classify rows, they do not handle entity relationships, and they do not read relational databases. If your task is “predict tomorrow's demand,” they are excellent. If your task is “predict which customer will churn,” they are the wrong tool.
The 6 real foundation models for structured data in 2026
Cut through the noise. Here are the only models that are actually pre-trained, actually make predictions on structured data, and actually exist as usable products or published research:
- KumoRFM 2.0 (Kumo.ai) - The only relational foundation model. Reads single tables and multi-table relational databases (5-50 connected tables). Graph transformer pre-trained on tens of thousands of real relational datasets. 91% on SAP SALT, 76.71 AUROC on RelBench. Sequoia-backed. Runs natively in Snowflake and Databricks.
- TabPFN v2.5 (PriorLabs) - The leading single-table FM. Transformer with in-context learning, pre-trained on 130M synthetic datasets. #1 on TabArena, published in Nature (Jan 2025). Open-source up to 50K rows, enterprise edition to 10M. Single flat table only.
- NEXUS (Fundamental) - Large Tabular Model with a non-transformer architecture. $255M Series A from Oak HC/FT and Salesforce Ventures. Claims billions of rows. No published third-party benchmarks as of early 2026. Single flat table only.
- NICL (Neuralk AI) - PFN-based tabular FM targeting commerce. Pre-trained on 150M+ synthetic datasets. $4M pre-seed. On par with TabICL on OpenML. Single flat table only.
- TabICL (INRIA, academic) - Transformer with column-then-row attention. Matches TabPFN v2 at up to 10x speed. ICML 2025. Single flat table only.
- CARTE (INRIA, academic) - Graph-attentional network for cross-dataset transfer. Beats XGBoost on small datasets. NeurIPS 2024. Single flat table only.
Notice the pattern: five of six are single-table only. KumoRFM 2.0 is the only one that reads relational data natively, and the only one with published enterprise benchmarks (SAP SALT, RelBench).
The detailed comparison:
foundation_models_structured_data_comparison_2026
| model | company | architecture | data_input | max_scale | published_benchmarks | funding |
|---|---|---|---|---|---|---|
| KumoRFM 2.0 | Kumo.ai (USA) | Graph transformer, pre-trained on 10,000s of real relational datasets | Single-table AND multi-table relational (5-50 connected tables via foreign keys) | 100M+ rows across dozens of tables | 91% SAP SALT (vs 75% PhD+XGBoost); 76.71 AUROC RelBench zero-shot (vs 62.44 LightGBM); 81.14 fine-tuned | Sequoia Capital |
| TabPFN v2.5 | PriorLabs (Germany) | Transformer, in-context learning, pre-trained on 130M synthetic datasets | Single flat table only | 50K rows / 2K features (open-source); 10M rows (enterprise) | #1 on TabArena; matches tuned XGBoost on single-table benchmarks; Nature 2025 | EUR 9M pre-seed (Balderton Capital) |
| NEXUS | Fundamental (USA) | Non-transformer (proprietary), pre-trained on billions of tabular datasets | Single flat table only | Claims billions of rows | No published third-party benchmarks as of early 2026 | $255M Series A (Oak HC/FT, Salesforce Ventures) |
| NICL | Neuralk AI (France) | PFN architecture, pre-trained on 150M+ synthetic tabular datasets | Single flat table only | 1M rows, 500 features | On par with TabICL on OpenML benchmarks; claims to outperform XGBoost on small data | $4M pre-seed |
| TabICL | INRIA (France, academic) | Transformer with column-then-row attention | Single flat table only | 500K rows | Matches TabPFN v2, up to 10x faster; ICML 2025 | Academic research |
| CARTE | INRIA (France, academic) | Graph-attentional network on row-level star graphs | Single flat table only | Best on small datasets (<2K rows) | Beats XGBoost on small datasets; NeurIPS 2024 | Academic research |
Highlighted: KumoRFM 2.0 is the only foundation model that reads both single-table and multi-table relational data. Every other model requires a single flat table as input. Note the benchmark column: KumoRFM and TabPFN have published, peer-reviewed results. Fundamental NEXUS ($255M funded) has not published any third-party benchmarks.
Why multi-table matters more than model architecture
There is a lot of debate about architecture right now: transformers vs. non-transformers, in-context learning vs. fine-tuning, synthetic pre-training vs. real data. These differences matter if you are comparing models on the same flat table. But for enterprise data, they miss the bigger question: can the model actually read your data?
Enterprise databases are relational. Customers connect to orders. Orders connect to products. Products connect to reviews. Reviews connect back to other customers. Fraud detection needs to trace transaction networks 6-7 hops deep to find ring structures. Churn prediction needs to compare a customer's behavior against structurally similar customers across product usage, support interactions, and purchase patterns. Retail recommendations need the full product-customer-session graph.
Flattening all of that into a single table so TabPFN or NEXUS can read it is like flattening an org chart into a list of names. You keep the names. But you lose who reports to whom, who has dotted-line relationships to whom, how deep each part of the org goes, and which teams work together across divisions. Need a headcount? The flat list is fine. Need to understand organizational dynamics? The flat list tells you nothing.
what_flattening_destroys_by_use_case
| use_case | critical_relational_signal | relationship_depth | survives_flattening |
|---|---|---|---|
| Fraud detection | Ring structure: accounts sharing devices, addresses, or beneficiaries with known fraud | 6-7 hops (account → device → other accounts → transactions → merchants → other accounts → fraud labels) | No - ring patterns are invisible in flat tables |
| Churn prediction | Similar-customer churn wave: customers with overlapping product usage and support patterns churning | 4 hops (customer → products → other customers using same products → their churn outcomes) | No - cross-customer similarity requires graph traversal |
| Retail recommendation | Collaborative filtering through purchase graph: customers who bought similar product bundles | 3-4 hops (customer → orders → products → other customers' orders → products they bought) | No - purchase graph collapses to aggregate counts |
| Lead scoring | Colleague signal: other contacts at the same company who engaged, attended events, or converted | 3 hops (contact → company → other contacts → their conversion outcomes) | No - company-level engagement patterns lost |
| Demand forecasting | Substitution effects: demand shifts between related products when one goes out of stock | 2-3 hops (product → category → similar products → their demand patterns) | Partially - but cross-product temporal dynamics lost |
For every major enterprise prediction task, the strongest predictive signals exist in multi-hop relationships across tables. These signals are permanently destroyed when data is flattened for a single-table foundation model.
This is why the accuracy gap between tabular FMs (on flattened data) and relational FMs (on native relational data) is so large - 15-20+ AUROC points on benchmarks with 5+ tables. It is not a modeling gap. It is an information gap. The data was destroyed before the model ever saw it.
KumoRFM 2.0: the only FM that does both
KumoRFM 2.0 handles both single-table and multi-table relational data in one model. It is not a compromise between the two. It is a superset: everything a tabular FM does on flat tables, plus the relational capability that none of them have.
- On single-table tasks: KumoRFM 2.0 delivers competitive zero-shot accuracy with no feature engineering, comparable to TabPFN and XGBoost. Teams that want to start with a single table can do so immediately.
- On multi-table relational tasks: KumoRFM 2.0 reads 5-50 connected tables directly using a graph transformer architecture, discovering multi-hop predictive patterns (2-hop, 3-hop, up to 7+ hop signals) across table boundaries. This is where the accuracy advantage is transformational: 91% vs 75% on SAP SALT, 76.71 vs 62.44 AUROC on RelBench.
We support single-table because people ask for it, and it works. You can start there today. But here is what we have seen over and over again: teams start with a single table, get decent results, then connect their full relational schema and see a step change. The reason is simple. When your data lives in 5-50 tables, the single table is just a shadow of the full picture. You are spending hours or weeks on feature engineering to squeeze signal out of that one table, when the real signal is sitting in the connections between tables. Connecting those tables is where the 15-20+ AUROC point jump comes from.
Enterprise benchmarks: published results
A lot of companies claim enterprise readiness. Published benchmarks are how you tell who actually delivers. Here are the numbers.
sap_salt_enterprise_benchmark
| approach | accuracy | setup_effort | data_structure |
|---|---|---|---|
| LLM + AutoML | 63% | Automated feature generation + model selection | Flattened single table |
| PhD Data Scientist + XGBoost | 75% | Weeks of expert feature engineering, hand-tuned model | Flattened single table |
| KumoRFM 2.0 (zero-shot) | 91% | Zero feature engineering, zero training | Native multi-table relational |
SAP SALT enterprise benchmark: real business prediction tasks on production-quality enterprise databases. KumoRFM outperforms PhD-level data scientists by 16 percentage points. The gap comes from reading relational structure that flat-table approaches cannot access. Note: single-table FMs like TabPFN and NEXUS cannot participate in SAP SALT because it requires multi-table enterprise data.
relbench_benchmark_7_databases_30_tasks
| approach | AUROC | feature_engineering | data_input |
|---|---|---|---|
| LightGBM + expert features | 62.44 | 12.3 hours, 878 lines of code per task | Flattened single table |
| Graph Neural Networks (custom) | 75.83 | Moderate (schema definition required) | Relational |
| KumoRFM 2.0 (zero-shot) | 76.71 | Zero - fully automatic | Native relational tables |
| KumoRFM 2.0 (fine-tuned) | 81.14 | Minutes of fine-tuning | Native relational tables |
RelBench: 7 real-world databases, 30 prediction tasks, 103 million rows, 51 tables. KumoRFM zero-shot outperforms LightGBM with weeks of expert engineering by 14+ AUROC points. Fine-tuned, the gap widens to 19+ points.
Two compounding advantages flat-table FMs cannot close
The accuracy gap is not one problem. It is two problems that compound, and no amount of model improvement on a flat table fixes either one.
First: flattening creates a hard accuracy ceiling. When you flatten 5+ relational tables into one table for TabPFN or NEXUS, you permanently destroy 3rd-degree, 4th-degree, and deeper connections. In fraud detection, the ring structure that identifies coordinated fraud networks exists 6-7 hops deep in the relational graph. In a flat table, it does not exist. No model - no matter how sophisticated - can recover information that the data no longer contains. This is not a penalty. It is a ceiling.
Second: flat-table FMs have never seen relational patterns. TabPFN is pre-trained on 130 million synthetic single-table datasets. NEXUS is pre-trained on billions of tabular datasets. NICL is pre-trained on 150 million synthetic tables. None of them have ever encountered a multi-hop relationship, a cross-table temporal sequence, or a graph-structural pattern - because these do not exist in single-table data. KumoRFM is pre-trained on tens of thousands of diverse real relational datasets spanning different industries, schemas, and entity types. It recognizes relational patterns that flat-table models have no knowledge of.
The team behind KumoRFM
In a space where startups raise hundreds of millions without publishing a single benchmark, the team and research track record matter. KumoRFM was not built by people who just read about graph ML. It was built by the people who created it.
- Vanja Josifovski, CEO. Former CTO at Airbnb (led the AI/ML organization), former CTO at Pinterest (built the recommendation and ads ML systems). Over 20 years building ML systems at enterprise scale.
- Jure Leskovec, Chief Scientist. Stanford professor, co-creator of Graph Neural Networks (including GraphSAGE), former Chief Scientist at Pinterest. One of the most-cited researchers in machine learning, with 300,000+ Google Scholar citations. The graph ML foundations that the field builds on were largely created in his lab.
- Hema Raghavan, Head of Engineering. Former Sr. Director of Engineering at LinkedIn, where she led ML infrastructure serving 900M+ members.
- Matthias Fey, Founding Engineer. Creator of PyTorch Geometric (PyG) - the most widely used graph neural network library in the world (23,600+ GitHub stars, 21M+ downloads). The toolkit that researchers and practitioners worldwide use to build GNN applications was created at Kumo.
Kumo is backed by Sequoia Capital, with advisors including Sridhar Ramaswamy (CEO, Snowflake), Matei Zaharia (CTO & Co-founder, Databricks), Ben Silbermann (Founder, Pinterest), and Frank Slootman (Board of Directors, Snowflake). KumoRFM runs natively inside Snowflake and Databricks - no data movement, no data export.
Flat-table FM workflow (TabPFN, NEXUS, NICL)
- Export data from your relational database
- Write SQL joins to combine 5-50 tables (hours to weeks of engineering)
- Manually compute aggregations, losing 3rd-7th degree connections permanently
- Feed the flattened single table to a model pre-trained on synthetic/flat data
- Get predictions limited by what survived the flattening step
- Repeat the entire pipeline for each new prediction task
KumoRFM 2.0 workflow
- Connect to your data warehouse (Snowflake, Databricks - one-time setup)
- Write a PQL query defining what you want to predict
- KumoRFM reads all relational tables directly - zero flattening, zero information loss
- Model pre-trained on 10,000s of real relational datasets recognizes cross-table patterns
- Zero-shot prediction in ~1 second, or fine-tune in minutes for maximum accuracy
- Next prediction task: write another PQL query (minutes, not months)
PQL Query
PREDICT fraud_flag FOR EACH transactions.transaction_id WHERE transactions.amount > 1000
One PQL query replaces the entire flattening pipeline. KumoRFM reads the raw transactions, accounts, devices, merchants, and beneficiaries tables directly, tracing 6-7 hop patterns through the relational graph to detect coordinated fraud rings that no flat-table model can see.
Output
| transaction_id | fraud_prob_kumo | fraud_prob_flat_model | why_kumo_differs |
|---|---|---|---|
| TXN-88201 | 0.94 | 0.52 | Kumo detects: shared device with 3 flagged accounts in fraud ring |
| TXN-88202 | 0.08 | 0.31 | Kumo correctly lower: strong merchant history, normal account graph |
| TXN-88203 | 0.91 | 0.47 | Kumo detects: beneficiary linked to accounts with rapid fund movement pattern |
| TXN-88204 | 0.03 | 0.05 | Both correctly low: established customer, consistent transaction pattern |
Decision framework: which foundation model should you use?
decision_framework_by_data_structure
| your_situation | recommended_approach | why |
|---|---|---|
| Single flat table, <50K rows, rapid prototyping | TabPFN v2.5 or KumoRFM 2.0 | Both deliver strong zero-shot accuracy. TabPFN is open-source and free. KumoRFM free tier at kumorfm.ai. |
| Single flat table, >50K rows, production | KumoRFM 2.0 or XGBoost/LightGBM | KumoRFM handles this scale natively. XGBoost with expert features remains competitive for large single tables. |
| Multiple relational tables (2-4) | KumoRFM 2.0 | Cross-table signals start appearing. Flattening tax: 5-10 AUROC points lost. |
| Multiple relational tables (5+) | KumoRFM 2.0 | Flattening tax: 15-20+ AUROC points. No flat-table model can compete. This is where KumoRFM's graph transformer + relational pre-training creates the step change. |
| Time series forecasting | Chronos, TimesFM, or Moirai | Purpose-built for temporal sequences. Not for tabular/relational predictions. |
| Enterprise relational database (Snowflake, Databricks) | KumoRFM 2.0 | Runs natively inside your warehouse. No data export. 91% SAP SALT with zero engineering. |
The right foundation model depends on your data structure, not just your data size. For single flat tables, several models are viable. For relational data - which describes most enterprise prediction tasks - KumoRFM 2.0 is the only foundation model that reads the full structure.
What the landscape gets wrong
We have read dozens of overviews on this topic. Most of them make the same three mistakes.
Mistake 1: mixing categories. Time series forecasting models (Chronos, TimesFM) predict the next value in a sequence. Tabular models (TabPFN, NEXUS, KumoRFM) classify rows and predict outcomes. These are different problems. Listing them together as “foundation models for enterprise data” is like grouping a weather model with a medical diagnosis model because both “make predictions.”
Mistake 2: including things that are not foundation models. DataRobot and H2O.ai train a new model from scratch every time. Timbr.ai helps LLMs talk to databases. Power BI makes charts. These are fine products, but they are not foundation models any more than a calculator is a computer.
Mistake 3: treating all structured data as flat tables. This is the big one. Enterprise data is relational. Multiple tables, connected by foreign keys. If you only evaluate foundation models on flat-table benchmarks, you miss the most important dimension entirely. On relational benchmarks (SAP SALT, RelBench), the gap between flat-table and relational approaches is 15-20+ AUROC points. Skip that and your comparison is incomplete.