Google's GPT-3 Moment for Databases & Spreadsheets (TabFM)

Author: Prompt Engineering · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Google’s GPT-3 Moment for Databases & Spreadsheets (TabFM) · Channel: Prompt Engineering · 10:45 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, Data, databases and embeddings, AI models

Summary

The video introduces TabFM, a Google Research foundation model for tabular data that uses labeled rows as context to predict labels for unlabeled rows, without training on each new dataset. It explains how the model is trained on synthetic tables and shows a churn-prediction example connected to a Postgres database. The presenter describes limitations around column meaning and semantic context, and a proposed agentic approach that uses an LLM to inspect columns and guide the pipeline. The video emphasizes safeguards for running data science agents, including isolated database branches and testing against historical snapshots to prevent data leakage.

Key points

Traditional tabular machine learning often requires cleaning data, engineering features, training a model, and repeating the process for each dataset.
TabFM uses labeled rows as context and predicts labels for unlabeled rows in a single pass, treating the dataset as its prompt.
The model was trained on synthetic tables generated from causal structures, with the goal of learning how to learn from tables.
The presenter demonstrates a customer churn prediction workflow using data in Postgres on Neon and TabFM running locally.
TabFM does not understand column headers or semantic distinctions between values, which can limit predictions on real-world tables.
An LLM-guided agent can inspect column names, write transformations, select context rows, and calibrate predictions.
The presenter uses isolated database branches as sandboxes so agent experiments do not mutate production data.
Historical database snapshots help prevent data leakage from columns populated only after an outcome occurs.
The presenter notes that TabFM weights are for non-commercial research use and presents the system as an architectural blueprint.

Chapters

Start	Chapter	Summary
00:00	Why tabular data needs a foundation model	The presenter contrasts repeated classical machine-learning workflows with TabFM, which uses labeled table rows to predict unlabeled ones.
03:11	A database-backed churn prediction example	The video introduces the Neon and TabFM setup and demonstrates churn scoring, while noting that TabFM lacks semantic understanding of columns.
05:52	Adding an LLM agent and database safeguards	The presenter describes an LLM-orchestrated pipeline and explains semantic grounding, isolated branches, and protection against data leakage.
08:33	Scheduled predictions and key takeaways	The workflow is used to generate recurring churn scores, followed by the main lessons about using table data as context and giving agents a safe backend.

Quotes

So, your data set is literally the prompt now. — 02:06

Tab FM weights are currently non-commercial research only. — 03:11

Now, it treats everything as a number. — 05:21

You can’t let an autonomous LLM mutate production data. — 06:58

give it a real back end to work in — 10:15

Concepts and entities

TabFM, TabFusion Auto, Google Research, Neon, PostgreSQL, Gemini, Opus 5.5, DGX Spark, vazamento de dados

Full transcript (original language)

00:00 Okay, so everybody’s obsessing over large language models right now, but almost all of this noise is about coding agents and chatbots. And LLMs are genuinely great for that, but if you look at what real businesses actually run on, it’s not text. It’s traditional tables. These include things like transactions, customer churns, sensor logs, fraud claims, and maybe inventory-related data. And whenever you need to predict something from a table, you can’t just use an LLM. People today still reach for traditional and

00:32 classical machine learning methods. But the problem with that is that every single new problem is going to need to train a whole new model from scratch. But today, I’m going to show you a model that might kill that workflow entirely. And then, I’ll show you how to wrap it around an autonomous data science agent that is running on a live back end. Now, personally, I have spent years building predictive models for tabular data and time series. Now, the recipe usually

01:02 looks something like this. You need to clean your data, then spend a lot of time hand engineering your features, then you train a classical machine learning model, especially gradient boosted trees type of models, tune hyperparameters, and then you repeat the exact groundwork for the next data set. Now, text used to be just as painful. You train one model for sentiment, then you would need another model for spam classification, and yet another model

01:33 for translation. But then, GPT-3 dropped, and suddenly, you didn’t train separate models anymore. You just showed a foundation model a few examples in the prompt, and it magically figured out everything. Tables never had that moment until now. Google Research recently dropped TabFM, a foundation model built purely for tabular data. But, here’s the crazy part. You do not need to train this model on your own data set. The idea is that you simply pass on rows

02:06 where you already know labels, and then tag on the unlabeled rows you want predicted. And then, it uses the labeled data and infers the answer in a single pass on those unlabeled data. So, your data set is literally the prompt now. Essentially, this becomes a general foundation model for tabular data. But, how exactly Google did this? The research team behind this trained it entirely on endless stream of synthetic data, which [clears throat] were essentially synthetic tables. Now, for each they sample a random

02:38 causal tag, then generate rows from it, and force the model to predict held-out cells. The beauty is that it is not able to memorize a specific data set. It actually learns the meta algorithm on how to learn from tables. Now, especially if you have worked in any business setup, tabular data is an essential part of every organization, and that’s why I wanted to create this video. Now, a quick heads-up, Tab FM weights are currently non-commercial research only. So, treat this as an

03:11 architectural blueprint rather than a drop-in production code that you can use. Okay, so I’m going to show you some live examples of this, but the foundation model is only half the part of the story. The other half is where your live data is. And then, we need to give an agent that environment which it can actually process and work on. So, this is where today’s sponsor, Neon, comes into play. Neon gives you serverless Postgres with instant branching, auth, storage, and function in one spot. For this architecture, the

03:45 data lives in Postgres on Neon. Tab FM runs locally on my DGX Spark, and our agent is going to execute directly against the database engine. Okay, before going into details, let’s look at a simple example. Uh so, here’s a synthetic SaaS company uh data that I produced. It includes things like customer profile, product usage, invoices, and support tickets. And the goal is that we want to predict which customers are going to churn.

04:15 Now, in this case, we pull the raw customer table uh from Neon. We feed the label history into Tab FM. I’ll show you how to do that later in the video and ask it to score the remaining users. So, there’s no training involved at all. Now, the model gives us inferred churn score for every customer and then that data is written back into the Postgres table. Now, here’s the best part. With zero feature engineering on a single table, it was already beating a tuned

04:47 tree-based model that I had trained. Now, the score is uh 0.60, which is not great. And this kind of exposes one of the biggest problem with Tab FM. Now, Tab FM is trained purely on causal graphs, which are synthetically generated. This also means that it hasn’t seen a column header or label at all during its training process. So, it doesn’t even know the difference between uh different columns. Like, one column might represent uh monthly spend,

05:21 the other might be simply temperature. Now, it treats everything as a number. However, uh your tables can contain semantic meaning. So, for example, you might have a column which uses number 1 2 3 as labels for different events that have happened. Maybe zero means not measured or missing values could be represented by a special tag. But, Tab FM cannot take those semantic gaps into account. So, this is where a large language model

05:52 enters the loop. Because understanding semantic context is what large language models do best. Now, the researcher paired a large language model in a new architecture called TabFusion Auto. So, here they keep TabFusion frozen as the inference engine and put language model that is powering an agent in charge of the whole pipeline. In this case, the agent inspects column names, writes transformation logic, maybe select context rows, and then calibrates the prediction. And actually, the

06:25 researchers show that this setup can hit top rank in the Tab Arena benchmark. Now, unfortunately, TabFusion Auto’s code is not publicly available. So, I used Opus 5.5 to basically create our own implementation that is using Gemini as the orchestrator. Now, if you want to use this, I think it’s very critical to understand the need for a robust database architecture in order to support a model like TabFusion Auto.

06:58 So, let me explain. Okay, first, the agent needs semantic grounding. In Postgres, you can store data dictionaries directly as column comments. So, the agent can use the schema plus the inline comments to actually decide what type of code to write. Second, the agent needs a sandbox. You can’t let an autonomous LLM mutate production data. So, for every experiment, the agent spins up an isolated Neon branch, which is a full copy-on-write database clone ready in

07:28 just about a second. It creates feature tables, then test joins, and drops columns, and stores the run. Now, if something fails, we simply delete the branch. And the beauty of Neon is that it will still keep the production completely untouched. Okay, third and the most critical pieces that the agent needs protection against uh data leakage. In my data set, there is a retention of a column that only gets populated after a customer initiates cancellation.

08:02 Now, this is going to look like a silver bullet feature uh for any agent that is running. If you’re looking at today’s snapshot of the database, but that’s not a feature that is actually available because it shows previous past outcome. So, an agent should not be using it. In fact, in half my test runs, the agent noticed the correlation and completely ignored the temporal risk and baked it into the pipeline. Now, to fix that, I had the agent train against an isolated branch restored to

08:33 the exact timestamp before the prediction window. Now, during testing, when I checked both against what customers had treated next month, uh the one that looked perfect on uh was the worst model cuz it was using that leaky column. And the one without that leaky column actually did great. Now, for a real production system, this is not going to be a one-off prediction. For example, if you’re actually running a business and you want to look at which customers could potentially churn, you can simply save the agent’s pipeline

09:06 into the database, and a Neon function runs it on a schedule. So, for example, in my case, every night it builds the feature straight from Postgres, then queues a job where DGX Spark picks the job up and writes a score for every customer back into the database. And then, the at-risk list lands in the object storage right next to it. So, for the experimentation, I basically moved the clock forward a month, loaded what actually happened, and created the list. Most of the customer at the top had, in fact, asked to cancel, which

09:42 kind of shows you the power of Tab FM, especially if you wrap it around into the agentic loop. Okay, so what exactly should be the takeaway from this? First, a fair prediction on tables, the model doesn’t have to be trained on your data anymore. Your data can just be the prompt. Second, LLM is still really useful here, but not just as a predictor. It can be extremely useful for the part that reads the column names and brings in the domain knowledge. And third, if you’re going to let an agent do data

10:15 science, give it a real back end to work in, especially its own branch off for every experiment, and meaning of every column right next to the data, and a way to see the data exactly as it looked when the prediction would have been made. Now, Neon is a back end that I used for all of it. And I highly recommend to check it out. I’ll put a link to the paper and the GitHub repo. It’s a very interesting project. The rights are non-commercial,

10:45 but you can treat it as a pattern you can build on. Anyways, I hope you found this video useful. Thanks for watching, and as always, see you in the next one.