# Google's TabFM brings zero-shot prediction to BigQuery, but the benchmark that sells it is a chart in a blog post
> Google's TabFM promises tabular machine learning from one SQL command. The launch benchmark is a self-reported chart, and its real limits decide where it helps.
Canonical: https://brandonlazovic.dev/articles/tabfm-bigquery-honest-read/
Author: Brandon Lazovic
Published: 2026-07-07
## The short version
- TabFM is a real advance for zero-shot tabular prediction, but it is a useful tool with a narrow sweet spot, not proof it replaces the tuned gradient-boosted tree.
- TabFM's headline Elo scores exist only as a chart image in a blog post, on a leaderboard co-created by the teams behind two of the rivals it beats.
- The chart-topping entry is a 32-model ensemble that, per one independent analysis, cuts median error by under one percent versus a single forward pass.
- In the author's own test, TabICL narrowly beat a tuned XGBoost on AUC, 0.932 versus 0.927, but took 59 seconds versus five milliseconds to score the test set.
Google introduced TabFM on June 30, a foundation model that promises machine learning on spreadsheet-shaped data with no training step, no hyperparameter tuning, and no feature engineering, and it is coming to BigQuery as a one-line AI.PREDICT SQL command. [1] The pitch is real and the underlying model is a genuine advance. But the benchmark doing most of the persuading is a chart image inside a blog post, and TabFM's own documentation draws limits that decide where this actually helps. Read as a data engineer rather than as a headline, TabFM is a useful new tool with a narrow sweet spot, not the end of the tuned gradient-boosted tree.
> The numbers that crown TabFM exist only as a chart image in a blog post, on a leaderboard co-created by the teams behind two of the rival models it beats. [1] [3]
## What did Google actually ship with TabFM?
TabFM is a foundation model for tabular data that makes predictions through in-context learning, the same few-shot trick large language models use when you paste examples into a prompt. Instead of training a model on your dataset, you hand TabFM your labeled example rows and the rows you want predicted as a single input; it infers the pattern and returns predictions in one forward pass, with no fitting, tuning, or feature engineering in between. [1] [2] A "forward pass" here just means one trip through the model, the cheap inference step, rather than a training run.
Architecturally, Google says TabFM "synthesizes the strengths of" two existing research models: TabPFN, which alternates attention across columns and rows so the model reads feature interactions natively, and TabICL, which compresses each row into a single vector before running the in-context learning step, which is what keeps the compute cost down on larger tables. [1] [4] [5] It was trained entirely on hundreds of millions of synthetic tables generated from structural causal models, algorithmic recipes that encode cause-and-effect relationships between variables, because real industrial tables are proprietary and scarce. [1] On TabArena, a public leaderboard for tabular models, Google reports TabFM topping both classification and regression. [1] [3]
## Is this a breakthrough or a recombination?
TabFM is a recombination, and Google says so in its own words. The blog describes TabFM as synthesizing TabPFN and TabICL, and both are real, published research: TabPFN v2 appeared in Nature in 2025, and TabICL was published at ICML the same year. [1] [4] [5] What is notable is what TabFM ships without. Its ancestor TabPFN has a peer-reviewed paper that states a precise training scale, around 130 million synthetic datasets; TabFM has only a blog post, a model card, and a GitHub README, and reports a vaguer "hundreds of millions" with no exact figure and no paper to review. [2] [4]
That matters because this is now a market, not just a research curiosity. SAP announced in May 2026 that it is acquiring Prior Labs, the company behind TabPFN, and committing to invest more than one billion euros over four years to build it into a frontier AI lab; the acquisition price itself was not disclosed. [12] So the honest framing is that TabFM's differentiator is not a new mechanism; it is Google-scale distribution. The novelty is putting a model from this research line one SQL command away inside the warehouse where your data already lives.
## How much should you trust the benchmark that crowns it?
Treat TabArena's Elo ranking as self-reported until someone reproduces it. The Elo ratings that rank TabFM first, Elo being the chess-style score TabArena computes from head-to-head win rates, appear only inside a chart image in Google's post; the body text never states the numbers, and they could not be reproduced against the live TabArena leaderboard. [1] [3] TabArena itself is credible and not controlled by Google, which cuts in Google's favor. But its maintainers are affiliated with AutoGluon (Amazon) and Prior Labs, the maker of TabPFN, two of the rival entries TabFM is charted against; that does not make the numbers wrong, but it is not a disinterested scoreboard either. [3] [16]
Two structural problems sit inside the chart. First, no tuned XGBoost, LightGBM, or CatBoost appears anywhere in the top ten, and a tuned gradient-boosted tree is exactly the model most engineers would actually reach for on a mid-sized table; a Hacker News thread on the launch flagged the missing baseline as a warning sign. [1] [8] Second, the entry that tops the chart is not the plain model. It is "TabFM-Ensemble," a 32-model blend that adds cross-feature and SVD inputs, compared against several competitors shown at their default settings, which is not a like-for-like contest. [1] An independent analysis of that ensemble found it cuts median error by under one percent over a single forward pass, for 32 times the inference cost. [15]
## Does AI.PREDICT exist yet, and what will it look like?
AI.PREDICT does not exist in BigQuery yet, but its sibling already shows the shape it will take. As of early July 2026 there is no AI.PREDICT function, documentation page, or release note; the only statement is Google's "in the coming weeks." [1] The precedent is AI.FORECAST, which Google shipped in 2025: a one-line SQL call backed by its TimesFM foundation model that forecasts time series with no model to train and no endpoint to manage. [6]
BigQuery now runs two families of prediction functions, and the split is the whole story. The ML.* family (CREATE MODEL, then ML.PREDICT) gives you a versioned model artifact you own, can pin, can roll back, and can explain; the AI.* family calls a foundation model Google hosts, with zero setup and correspondingly less control. [7] AI.PREDICT will almost certainly be TabFM slotted into that AI.* pattern for classification and regression.
The catch a data engineer should mark is what you give up for that convenience. With a hosted foundation model you do not own the version the way you own a model you trained; AI.FORECAST already exposes more than one TimesFM version (2.0 and 2.5, with 2.0 as the default), and the model behind the call is Google's to update, re-default, and eventually deprecate. [17] I call this vendor-versioning risk, and it is a different problem from classical model drift: you never trained the model, so you cannot pin and roll back to the exact version you validated against. There is a second flag specific to in-context learning: because the model reads your labeled rows as context on every call, that data travels to the endpoint each time rather than being baked into a trained artifact once. [2]
## Where does a zero-shot tabular model genuinely help an e-commerce data team?
A zero-shot tabular model like TabFM helps most as a fast feasibility check on clean, small-to-mid tables, not as a replacement for a model you would ship. When you have no existing model and want to know whether a signal is even predictive, a single SQL call beats standing up a training pipeline to find out; that is a real, if unglamorous, win for a cold-start problem or a quick triage. The e-commerce jobs that genuinely fit its shape are the flat, labeled, moderate-size ones: churn, purchase or conversion propensity, transaction-level fraud, and lead scoring.
The jobs people will wrongly attach to it are the text problems. Keyword clustering and product categorization or attribute extraction are not tabular tasks; a tabular model cannot ingest a raw product description at all, and naming that distinction precisely is how you avoid buying a tool for the wrong job. There is also an uncomfortable adoption fact: as of mid-2026 I could not find a single public e-commerce production deployment of this model family, TabPFN, TabICL, or TabFM, despite a mature research footprint; documented production use clusters in fintech, healthcare, and industrial maintenance. I will label that as my own search result rather than a published statistic, but the pattern is consistent. The strongest e-commerce-adjacent win on record, Booking.com's fraud model, came from building their own model on proprietary data, which is closer to the opposite of the zero-shot pitch. [14] And when a fintech lender benchmarked a sibling model for credit risk, it declined to adopt it. [13]
## Where does it break, and when should you still reach for XGBoost?
Reach for a tuned gradient-boosted tree when your data is large, wide, many-class, drifting, or when someone needs to know why a prediction was made. TabFM's own model card caps classification at ten classes and says quality degrades past roughly 500 features, and because all your reference rows ride along as context, memory grows with the data. [2] An independent stress test of TabFM hit out-of-memory past about 20,000 context rows on a 24GB GPU, and clocked 31 seconds per prediction on that GPU against roughly 21 minutes on a CPU at 5,000 rows. [9] Academic work on the TabPFN lineage puts the practical envelope near 10,000 rows, 500 features, and 10 classes, beyond which it ranks below CatBoost and a tuned neural baseline, and on high-dimensional data fails to beat plain logistic regression. [10]
Accuracy is not the only axis. A reliability study of tabular foundation models found they can win on raw accuracy but lose on calibration, how well a model's confidence matches reality, and concluded that gradient-boosted trees remain the more reliable choice on noisy, heterogeneous data. [11] Add the interpretability gap, since there is no mature, ubiquitous feature-attribution path for these models the way TreeSHAP serves gradient-boosted trees, and the latency the fintech benchmark measured at orders of magnitude slower than its production model, and you have a clear picture of when the boring, tuned tree is still the right answer. [13]
## What happens when you run a zero-shot model against XGBoost yourself?
A zero-shot tabular model can edge a tuned XGBoost on a small e-commerce table, but the win is narrow and it pays for it in speed. I ran the test Google's chart left out. On the UCI Online Shoppers Purchasing Intention dataset, about 12,000 real shopping sessions where the task is predicting which ones end in a purchase, I gave both models the same stratified 4,000-row training sample and the same held-out test set. [18] Because the hosted TabFM is not released yet, I used TabICL v2 as the stand-in: it is one of the two published models TabFM is built on, and it is one of the entries in the leaderboard chart above. [5]
The zero-shot model won on ranking quality, by a little. TabICL scored 0.932 AUC, the probability it ranks a converting session above a non-converting one, against the tuned XGBoost's 0.927, with no tuning at all; a default, out-of-the-box XGBoost trailed at 0.911. Calibration was close, and on this clean dataset if anything slightly better for the zero-shot model (a Brier score of 0.072 versus 0.074); the reliability gap the research warns about tends to show up on noisier, more heterogeneous data than this. So the "competitive with a tuned tree, straight out of the box" claim held up here, which is the honest case for reaching for one as a fast feasibility check.
The cost showed up in speed. Scoring the same test set took the zero-shot model about 59 seconds on a CPU; the tuned XGBoost, once trained, did it in about five milliseconds. A zero-shot model reprocesses its entire training context on every prediction, while a trained tree just walks a fixed set of splits, so that gap is structural, not a tuning detail. It is the difference between a batch triage tool and something you could put in a checkout-time decision, and it is the cost the launch materials do not mention.
## What should you actually do about it now?
Watch for the AI.PREDICT preview in BigQuery, use it for triage, and keep your trained models for anything that ships. TabFM is worth real attention because the pattern behind it, a foundation model you call from SQL, is where the warehouse is heading; it is not worth throwing out a pipeline that works. The moves below are my translation of the evidence into actions, not Google's recommendations.
| If this is true | Then the move is |
|---|---|
| AI.PREDICT is a one-line call with no training step | Use it to sanity-check whether a signal is predictive before you invest in a full pipeline, not as the pipeline. |
| Trained models stay versioned, explainable, and fast | Keep XGBoost or BigQuery ML boosted trees for production scoring, large or wide tables, many classes, and anything a stakeholder needs explained. |
| A hosted model reads your rows and Google owns the version | Before you run customer data through it, get answers on pricing, data handling, and versioning; treat vendor-versioning risk as a first-class concern and pin nothing you cannot reproduce. |
| The launch benchmark is self-reported and incomplete | Wait for an independent reproduction with a tuned gradient-boosted baseline before you trust a ranking, and run your own holdout on your own data. |
The genuinely interesting story is not that Google beat XGBoost on a chart. It is that the data warehouse is quietly becoming the place you call a foundation model, first for forecasting with AI.FORECAST, now for classification and regression with AI.PREDICT. [6] The discipline that will matter is the same one that has always separated a durable data practice from a fragile one: knowing exactly what the one-line call is doing, and what it is not.
## Sources
1. Introducing TabFM: A zero-shot foundation model for tabular data (Google Research) — https://research.google/blog/introducing-tabfm-a-zero-shot-foundation-model-for-tabular-data/
2. google/tabfm-1.0.0-pytorch model card (Hugging Face) — https://huggingface.co/google/tabfm-1.0.0-pytorch
3. TabArena: A Living Benchmark for Machine Learning on Tabular Data (Erickson, Hutter, Purucker et al., NeurIPS 2025) — https://arxiv.org/abs/2506.16791
4. Accurate predictions on small data with a tabular foundation model, TabPFN v2 (Hollmann et al., Nature, 2025) — https://www.nature.com/articles/s41586-024-08328-6
5. TabICL: A Tabular Foundation Model for In-Context Learning on Large Data (Qu et al., ICML 2025) — https://arxiv.org/abs/2502.05564
6. The TimesFM model and AI.FORECAST (BigQuery documentation) — https://docs.cloud.google.com/bigquery/docs/timesfm-model
7. The CREATE MODEL statement for boosted tree models (BigQuery ML documentation) — https://cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-syntax-create-boosted-tree
8. Hacker News discussion of the TabFM announcement — https://news.ycombinator.com/item?id=48739919
9. Yash Raj Pandey, I Tried to Break Google's New Tabular Foundation Model (independent stress test) — https://yashrajpandey.com/writing/breaking-google-tabfm/
10. A Closer Look at TabPFN v2 (Ye et al., 2025) — https://arxiv.org/abs/2502.17361
11. High Performance, Low Reliability: Uncertainty Benchmarking for Tabular Foundation Models (2026) — https://arxiv.org/abs/2605.28554
12. SAP to acquire Prior Labs and establish a frontier AI lab in Europe (SAP News, May 2026) — https://news.sap.com/2026/05/sap-to-acquire-prior-labs-establish-frontier-ai-lab-europe/
13. Mission Lane, TabICL Under the Microscope: benchmarking tabular foundation models for enterprise credit risk — https://medium.com/mission-lane-tech-blog/tabicl-under-the-microscope-benchmarking-tabular-foundation-models-for-enterprise-credit-risk-ad8315f9bec4
14. Booking.com, self-supervised transformer for fraud detection (2024) — https://arxiv.org/abs/2405.13692
15. AI Crucible, TabFM ensembling: wins, even for tables — https://ai-crucible.com/articles/tabfm-ensembling-wins-even-for-tables/
16. Christoph Molnar, TabArena explained (Mindful Modeler), which lists TabArena's creator affiliations (AWS/AutoGluon, Prior Labs) — https://mindfulmodeler.substack.com/p/tabarena-explained
17. The AI.FORECAST function, documenting supported TimesFM versions 2.0 and 2.5 with 2.0 as default (BigQuery documentation) — https://docs.cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-syntax-ai-forecast
18. UCI Machine Learning Repository, Online Shoppers Purchasing Intention Dataset (Sakar et al., 2019) - used in my own benchmark run — https://archive.ics.uci.edu/dataset/468/online+shoppers+purchasing+intention+dataset