A data change that used to take three weeks now takes an afternoon. And the AI agents don’t make things up; they can’t. They act on data that’s exact, versioned, and deterministic.
That’s Tabsdata 2.0, shipping today. If the one-liner is all you came for, there it is.
I’ve been chasing this exact idea, on and off, for many years. So let me back up.
Early 2009. If you wanted a video call with someone across an ocean, you didn’t open an app; you booked a room. Cisco gear, wall-to-wall monitors, the whole setup solemn enough that you half expected to be negotiating a hostage release. Zoom wasn’t a thing yet. I was at Yahoo India back then, on the big data team, when Hadoop wasn’t so much a technology as a religion. My team built a workflow engine for those big data jobs; you might know it as Apache Oozie.
On one of my trips to the Santa Clara campus in California I show up for a meeting with Raymie Stata, Yahoo’s chief architect at the time, and, if memory serves, Patrick Hunt. Raymie is pitching an idea: a big data storage system built on immutable, versioned datasets. Data factories, I think he called them, well before Azure went and claimed the name. At what was Yahoo back then, the sheer amount of data that would imply was, and still is, obscene. Then the usual happened; reorgs, priorities shifting under our feet, and at least for me, we never got into the details.
I moved on, joining Cloudera and StreamSets after that. In StreamSets we built one of the first streaming ETL platforms; maybe the first, depending who you ask. Fast forward to mid 2024. Still data integration; karma or dharma, I still haven’t worked out which. With Arvind Prabhakar (of StreamSets fame, and an old sparring partner from my Sun Microsystems and Cloudera days) we sat down and started dreaming about what data integration should actually look like today, based on what we’d built, what was out there, what customers kept telling us, and what current and upcoming tech finally made possible.
Here’s the thing. Data integration is probably one of the first problems any organization ran into the moment IT worked its way into how it actually operates. And yet, for a lot of people, it still feels closer to the Flintstones than the Jetsons. You juggle a pile of tools, sometimes dressed up as a single one, until you notice the seams: buttons here, levers there, a pull-cord you were apparently supposed to know about; every task a different interface, a different way of describing what you want done. Atado con alambre, we say in Argentina; duct-taped, they’d say in the US.
We set out to simplify all of that, to hand the power back to developers, and, maybe most of all, to keep their free time free. No more losing a Saturday because someone upgraded a system without telling the right people, or something broke because someone rotated a password. Reconciling that mess and getting everything back on the rails is nobody’s idea of a weekend.
And it’s not just the fires. Most of the time the thing you need is almost insultingly small. A tweak here. One more column. A new source someone in finance just spun up last Tuesday. Point that pipeline at a different warehouse because the company signed a new contract. None of it is hard. None of it is the kind of work that should cost anyone a week.
But here’s the quiet catch, the one nobody puts on a slide: the person who feels the need is almost never the person who can act on it. So you file a request, and you join the queue. And the queue is its own particular kind of purgatory: take a number, find a seat, watch the little display that never seems to move. Now serving: 3. Somewhere behind a counter a small, overworked data team is doing its honest best, but there’s only so much of them and an entire company keeps pulling tickets. The change that would’ve taken twenty minutes if you could’ve just done it yourself now takes three weeks, two stand-ups, and a Slack nudge you swear isn’t passive aggressive.
Multiply that by every source, every destination, every “quick” little change, across every team that so much as breathes on data, and you get the real tax of data integration. Not the big dramatic outage everyone writes postmortems about. The slow one. The waiting. And the whole time, the person who could’ve fixed it in twenty minutes was sitting right there, holding a ticket.
We kept coming back to that person in the chair. Not “how do we make the data team faster” — that’s the answer everyone reaches for, and it just buys a bigger counter. The question that stuck with us was quieter, and a little uncomfortable: how much of that queue needs to exist at all?
Here’s the part that changes everything, and it’s almost boring: Moore’s law, and its storage-side cousin, kept the promise. Compute got cheap. Storage got cheaper. Keeping immutable, versioned copies of basically everything, the thing that was economically unthinkable in 2009, is now just a line item.
Immutable versioned data as a given rather than a luxury; imagine the possibilities. Once the system already holds the full history of every dataset, a whole catalog of things that used to be expensive, hard-won features stop being features at all; you get them as a side effect of how the storage works. Full lineage? You kept every version, so you already have it. The pristine state, the entire system as it was ten days ago? Just a coordinate in data you never threw away. “What exactly ran last Tuesday”? You kept the receipts, so you can always go check.
So the uncomfortable little question becomes: if the expensive thing is affordable now, why are so many of us still doing it the cheap, broken way?
So. What if you had a system where you could (and to be clear, you wouldn’t *have* to; why do a thing the right way when there are so many gloriously wrong ways still on the menu?)…
…where you don’t need to wire things end to end. The data owner lands their data, curates it first if they want, and whoever needs it comes and takes it. The system, not a cron job, not a human remembering to click a button on Friday, gets the right data to the right place the moment it exists. From the ask to being exactly where you wanted to be: hours, not months. Nought to sixty, and the clock starts the moment you ask.
…where you can rewind. Not just “what did this table look like last Tuesday,” but what did the *entire system* look like at that exact moment, the code, the data, all of it. We call it the pristine state, and it turns “something looks off, and not just today” from a forensic nightmare into a question you can actually answer.
…where the processing is deterministic. Fully. Same inputs, same outputs, every single time, so “well, it worked on the last run” stops being a prayer. This is the boring superpower. It’s also, as we’ll get to, the entire reason the AI parts don’t quietly fall apart.
And the part that matters most: one system. Not a constellation of dysfunctional tools, each heroically failing at its own slice and duct-taped to the next. One system.
Bonus round: it runs on your laptop and on a full-blown Kubernetes cluster. Same system, same code. What the developer runs is what production runs; no “works on my machine,” no separate prod reality lying in wait.
And all of it both powered by AI agents and feeding them, because the one thing an agent needs to stay on the wagon is exact, deterministic data underneath it. Give an agent solid ground and it stops making things up.
Here it is
That system is not a what-if. Tabsdata is a data integration platform built on that single premise: every table in it is immutable, versioned, and produced by deterministic functions. Data owners publish tables; consumers subscribe to them; transformers sit in between. That’s the whole programming model. You declare what data goes where; Tabsdata works out the how — the loading, the processing, the storing, the moving — the moment the data exists.
Everything from the what-if list falls out of that premise instead of being bolted onto it. Lineage is a record, not a reconstruction; replayability is a consequence, not a feature; the pristine state is a coordinate. ETL, data quality, transactional jobs, observability: one coherent model, not seven tools pretending to be one.
What 2.0 ships
Kubernetes-native execution. The bonus round is real. The same platform runs on your laptop — Windows, macOS, Linux — or on a Kubernetes cluster: AWS EKS today, additional distributions in upcoming releases. Storage scales on the cloud, processing scales on Kubernetes, and your functions don’t change. From a single machine to production without rewriting anything.
A living semantic catalog that builds itself. Not just the schemas of the systems you connect — a full classification of the data in them: what it is, what it’s likely for, and suggestions on how to use it. The catalog is a byproduct of the platform doing its job, not a second job you have to do.
Medallion tooling. The bronze/silver/gold patterns every data team ends up re-implementing — raw capture, quality observation, CDC handling, slowly changing dimensions — shipped as primitives you compose instead of folklore you rewrite.
An MCP server. Your AI agent — Claude, Codex, whichever you run — can drive Tabsdata end to end. More on this in a moment, because it’s the part that pays off the promise above.
A built-in AI agent. Inside the Tabsdata UI, focused on operational work: what ran, what failed, why, and what to do about it.
The agentic layer
I said the deterministic bit is the entire reason the AI parts don’t quietly fall apart. Here’s why.
AI agents don’t hallucinate about data systems because they’re careless; they hallucinate because the ground keeps moving. State is smeared across half a dozen tools, tables get overwritten in place, and the agent ends up reasoning over a snapshot that stopped being true while it was reading it. Given partial visibility, a language model does what language models do: it fills the gaps, confidently.
Tabsdata removes the gaps. Every table the agent looks at is immutable and versioned; every function that produced it is deterministic; the full lineage of how anything came to be is a record, not an inference. The agent isn’t guessing what probably happened; it’s reading what did happen, at the exact version it happened. Solid ground, no gaps left to fill.
There are two ways in.
The first is the Tabsdata MCP server, and its design is, in the best tradition of this post, boring: it is just a Tabsdata client. It is subject to exactly the same authorization rules you are. No service account with god mode, no side channel, no backdoors; if you can’t do something in Tabsdata, neither can your agent. It ships with a skill library — precise, tested instructions for operating the platform — so the agent works from documentation rather than vibes. Point Claude, Codex, or whatever you run at it, and it can discover data through the living semantic catalog, trace lineage, inspect executions, and build pipelines. As you, with your permissions, on data that doesn’t lie.
The second is the agent built into the Tabsdata UI, aimed at operational tasks: the “what ran last night, what failed, why, and what now” conversations that otherwise mean twenty minutes of digging through logs.
Enterprise-grade AI on data infrastructure isn’t a bigger model or a longer prompt. It’s determinism underneath and authorization on top. That’s the architecture.
Get it
Tabsdata 2.0 is out today.
Start on your laptop; the quick start takes minutes. When you outgrow the laptop, the same system runs on Kubernetes. That was the whole point.
- Tabsdata: https://tabsdata.com
- Quick start: https://docs.tabsdata.com/guide/introduction
- Docs: https://docs.tabsdata.com
Now serving: everyone.