Dremio just sold to SAP. That single deal is worth pausing on, not because of what it says about one vendor, but because of what it says about the whole lakehouse-engine category.
Dremio built for a specific bet: bring your data into one lakehouse, and get a fast, well-tuned engine for querying it there. That bet made sense for a while. A lot of workloads really do fit inside one lake, and an engine optimized for exactly that case can compete on its own terms.
AI is what’s breaking that bet, for Dremio, and for every engine built the same way.
Agents don’t sit inside one lake and wait their turn. They reason across the whole estate, fire off dozens of queries at once, and expect current answers at production speed. If an agent can’t reach a system, it can’t reason about what’s in it. That gap becomes a gap in its judgment. What used to be a nice-to-have for analytics is now the precondition for trustworthy AI, and federation, querying everything, wherever it lives, without moving it first, is the only architecture that delivers it.
That’s the pattern worth watching, and Dremio’s sale is just the clearest data point so far. Here, we’re using it as the entry point into a bigger question: what happens to every lakehouse-only engine once AI stops tolerating a data platform that can’t reach everything?
The short version: Dremio, like most of that category, was built to bring data into the lake first, and that scope decision is exactly what’s now getting tested by workloads it was never designed for. Worth sitting with why, because the reason is more specific than “AI needs more data”. It’s about what reach actually does to an agent’s output, and most of the industry conversation skips past it.
Reach isn’t a performance number. It’s a judgment number.
Here’s the part that doesn’t get said plainly enough: an agent’s reasoning is bounded by what it can see, in a much more literal way than a person’s is.
A human analyst who only has access to one system still knows, in the back of their mind, that there’s more data out there. They caveat. They say “based on what I can see” without being told to. An agent doesn’t have that instinct unless someone builds it in — and mostly, nobody does. An agent reasons over what’s in front of it and reports the answer with the same confidence whether it queried one system or twenty. It doesn’t know what it doesn’t know.
That means a gap in data reach doesn’t just produce a slower answer or an incomplete dashboard. It produces a confident, wrong answer, delivered with the same tone as a correct one. An agent asked to assess churn risk that can only see the CRM and not the support ticket system isn’t giving you a partial answer. It’s giving you a complete-sounding answer built on a partial picture, and it has no way to flag the difference. That’s a much worse failure mode than latency. Latency tells you something’s wrong. A confidently wrong answer doesn’t.
This is why “how many sources can this engine reach” stopped being a checkbox on an RFP and started being the thing that determines whether you can trust anything the agent tells you. Reach was always an architecture question. Now it’s a trust question, and those get evaluated very differently.
Agents don’t ask permission to be unpredictable
The second thing that’s changing is subtler and it’s about acceleration, not access.
Most lakehouse engines get their speed from precomputing: materialize the datasets you expect to be queried, refresh them on a schedule, and let queries hit the precomputed copy instead of the live source. That’s a completely reasonable trade when you can predict the query shape — dashboards ask the same handful of questions over and over, and precomputing those questions is smart engineering.
Agents break that assumption in a specific way. They don’t run a fixed set of queries repeated on a schedule. They generate new query shapes on the fly, in response to whatever the previous step in their reasoning surfaced. Ask an agent to investigate an anomaly and it doesn’t run one query — it runs a query, looks at the result, and generates a follow-up query nobody wrote in advance, based on what it just found. That’s the whole value of agentic reasoning: it can go where the evidence leads instead of running a pre-approved script.
Which means the exact thing that makes agents useful is the exact thing that precomputed acceleration can’t plan for. You can’t materialize a view for a question that gets generated at runtime based on an answer you didn’t have five seconds ago. An architecture that depends on knowing the query in advance is, structurally, an architecture that can’t keep up with how agents actually operate — no matter how well it’s engineered for the queries it does anticipate.
What this actually asks of a data platform
Put those two things together and you get a fairly specific list of requirements that has nothing to do with any particular vendor:
Reach has to be close to total, not partial. Not “most of our data,” but the databases, warehouses, object stores, and SaaS systems an agent might need mid-reasoning, because a system it can’t reach isn’t a system it queries carefully. It’s a system it silently ignores, and neither you nor the agent will necessarily notice.
Access has to hold up at a concurrency nobody designed dashboards for. A person opens one dashboard at a time. A fleet of agents fires parallel queries continuously, and an engine that’s fast for one user and slow under real load is going to be slow exactly when it matters most.
Context has to arrive scoped, not dumped. An agent doesn’t benefit from being handed an entire schema, warehouse, or document corpus and told to figure it out — that’s how you burn the context window on noise and get reasoning errors on the parts that mattered. It needs the relevant slice: the right tables, the right columns, the right business definitions, assembled for the specific question being asked, not the whole catalog because someone couldn’t be bothered to scope it.
Freshness has to be structural, not scheduled. An agent asking a question that got generated ninety seconds ago needs an answer computed against current data, not against last night’s refresh. “How stale is acceptable” used to be a business decision. For a lot of agentic use cases, it’s now closer to zero.
Governance has to travel with the data, not sit beside it. If two agents draw two different conclusions from the same underlying numbers because they hit different systems with different business logic applied, that’s not a minor inconsistency — it’s the kind of thing that makes people stop trusting agentic output altogether, which defeats the entire point of building it.
None of that is Dremio’s problem specifically. It’s the requirement list AI is handing to every vendor in this category, whether they’re currently being acquired or not — and it’s worth measuring any platform you’re on, or any platform you’re evaluating, against that list directly rather than against a features chart.
Where we land on this
For what it’s worth, this is the argument that’s shaped how we’ve built Starburst — federating across sources rather than centralizing them, treating governance as something enforced at query time rather than layered on after, and optimizing for workloads that can’t be predicted in advance rather than ones that can. That’s a design philosophy, not a scoreboard, and it’s one other vendors are free to disagree with.
But regardless of which platform you’re evaluating, the questions above are the ones worth asking directly: can it reach what your agents will actually need, does it hold up at the concurrency they’ll generate, and does it answer a question it didn’t see coming five seconds ago. If a vendor’s answer to any of those is “we’re working on it,” that’s useful information too, just make sure you’re the one asking, not finding out after you’ve committed.
Dremio’s sale to SAP is one data point. It’s not the story. It’s the moment the underlying shift became visible for one vendor. The shift itself is bigger than that, and it’s not going to stop with one acquisition.
