The Last Mile of the Lakehouse

Why the lakehouse gets you most of the way to enterprise AI — and what closes the gap.

A regional VP asks a simple question: what were my EMEA bookings last quarter by product line, against plan? Three days later, a data engineer hands back a CSV.

The platform underneath that question is excellent. The lakehouse consolidated the warehouse and the lake, separated storage from compute, put a governance catalog over the top, and gave the data team a real place to build. By every infrastructure measure, the program was a success.

And yet the answer is still a ticket.

That is the moment the lakehouse meets its natural edge. Not in the architecture — which is excellent — but in the last mile to the person who actually needed the answer. That last mile was never the job the lakehouse was built to do.

I have spent close to thirty years selling into enterprise IT, and I want to be careful here. This is not a Databricks takedown. Databricks built something genuinely important, and if you bought it, you made a good decision. The point of this piece is the opposite: here is exactly the slice the lakehouse was never designed to solve, and what you add on top to finish it.

Part One

What the lakehouse got right

Give credit where it is due. Databricks solved the hard infrastructure problem of the last decade. Separated storage from compute. Unified the warehouse and the lake. Put governance under one catalog. Gave engineers and data scientists a single place to build pipelines and train models. When the work is data engineering, machine learning, or large-scale transformation, the lakehouse is a strong answer — and that is why the platform won.

Notice what those wins have in common. They are wins delivered for and through the data team. The lakehouse is built, operated, and consumed by technical specialists, and that is exactly right for what it does. The opportunity sits one step beyond it — with the people who most need answers from enterprise data and who do not sit on the data team.

The strongest architectures I see do not pit a lakehouse against everything else. They pair a best-in-class lakehouse with the layers it was never meant to be. The two are additive, and that is the whole spirit of this piece.

Databricks remains the right answer for engineering workloads, machine learning, and large-scale analytics. Anything I say from here forward should be read against that statement, not in tension with it.

Part Two

Where the lakehouse was never meant to go

Four forces shape the gap. None of them is a knock on Databricks. Each is a map of a slice of the funnel no lakehouse, by design, was built to own.

1. Accuracy collapses on real production schemas. The benchmarks the industry quotes are measured on tidy academic schemas of ten to twenty tables. Point a general-purpose text-to-SQL system at a real production estate and accuracy can fall by more than 90 percent.[5] This is not a Databricks failing; it is the limit of general-purpose AI when it meets enterprise schema scale, and the whole category shares it. It is also the load-bearing fact behind everything that follows.

2. The business user cannot fully self-serve at enterprise scale yet. Databricks saw this early — that is why Genie exists, and Genie is genuinely well engineered. Its own guidance is candid about scope: a Genie Space supports up to 30 tables, with a recommendation to aim for five or fewer, and the suggested approach for larger topics is to pre-join related tables into curated views first.[1] That is a smart accuracy guardrail, not a defect. But hold it against reality. A production SAP S/4HANA schema ships with more than 2,000 tables. Oracle EBS modules run into the hundreds. Workday, PeopleSoft — every serious system of record is a thousand-table problem. The modeling work still has to happen up front, and it still lands on the data team.

3. The expert remains in the loop by design. Independent analysis of the lakehouse transformation layer is candid about a pattern that shows up across every powerful technical platform: business analysts who understand the data and the business rules often cannot contribute directly, because the work requires engineering skills.[2] BARC’s 2026 review reflects the same dynamic from the buyer’s seat — the platform scores extremely well on capability, performance, and scale, with the points customers raise most being about business-user accessibility, and only 16 percent reporting no significant adoption hurdles.[3] Read that the right way and it is almost a compliment. It is what happens when a platform is deep enough to do nearly anything: it takes an expert to drive it.

4. Cold history sits in the hot tier. Any consumption-priced platform rewards you for keeping only active, high-value data in compute — and idle or inefficient compute is widely cited as the single biggest source of lakehouse spend.[4] Yet most enterprises keep years of legacy and retired application data in that same premium tier, queried twice a year, simply because there was never a clean place to retire it to. This is not a Databricks problem; it is a data-placement gap that predates the lakehouse entirely. The platform is a finely tuned sports car. The point is not to use it to haul gravel.

This was never a Databricks problem. It is a data-readiness problem.

This connects to the thesis I have been hammering for a year. MIT’s NANDA initiative found that roughly 95 percent of generative AI pilots are not delivering measurable P&L impact.[6] The reflex read is the tools do not work. The truer read is that the layer that makes enterprise data genuinely understandable to AI — at full schema scale, with governance intact — is the layer almost nobody built. The lakehouse is a magnificent floor. It was never designed to be that ceiling, and expecting it to be is what sends pilots into purgatory.

So the question for a Databricks customer in 2026 is not did I buy the wrong platform. You did not. The question is what completes it.

Where Solix Completes the Picture

Complementary, not competitive. Solix sits alongside the lakehouse and finishes the part of the job it was never meant to own — in three places.

It closes the last mile for the business user. Solix reads your environment as it already exists — hundreds or thousands of tables, in your real production schema — and builds a working understanding of how the tables relate and what the columns actually mean. No collapsing 2,000 tables down to 30. No hand-authored semantic layer that a data engineer maintains forever. Then a business user asks in plain English and gets an answer grounded in that understanding. And here is the single design choice that matters most: when a question is genuinely ambiguous, the system asks a clarifying question instead of guessing. The most dangerous output in the enterprise is the confident wrong answer. It is the one we built ours to refuse to produce.

It gives you a governed system of record so the lakehouse can do what it is best at. Through application retirement and a single governed repository, Solix becomes the immutable home for legacy and retired application data — the EBS, SAP, PeopleSoft, and mainframe history you are legally required to keep but should not be paying hot compute to store. The data stays fully accessible and AI-ready. Your lakehouse footprint gets lighter and cheaper. Your retention and compliance posture gets stronger. All in one motion.

It governs the AI itself. Governance, lineage, masking, and lifecycle policy apply to every operation by default — not as a bolt-on afterward. That is the part that lets a CFO actually sign off.

One platform that unifies enterprise data into a governed repository, builds enterprise AI directly on top of it, and makes that data AI-ready — in one place. Most of the market sells you one of those three and calls it a platform. We are not a competing lake. We are the readiness, governance, and business-access layer that makes the lake you already own finally pay off.

A decision framework, in one table

Where each layer is the right answer — and where they overlap.

Complementary, not competitive. The two layers are designed to work together.

Part Three

What I would tell a CIO running Databricks today

If I had ten minutes — and I have a version of this conversation almost weekly — here is what I would say.

Keep the lakehouse for what it is genuinely great at, and add a business-facing layer in front of it. The small-space guidance is telling you something true about where general-purpose AI naturally stops, not something wrong with the platform. Put a layer in front of it built for your real schema scale, and measure success by whether a regional VP can get a correct answer without filing a ticket.

Get your cold and retired data out of your hot tier. Every year of legacy application history sitting in consumption-priced compute is budget you are lighting on fire. A governed archive that keeps that data AI-ready is a cost story and a compliance story in the same move.

Make every AI vendor prove accuracy on your schema, with your naming, at your scale. And treat “the AI asks a clarifying question” as the feature it is. The tool that always answers is the tool that sometimes fabricates.

The lakehouse got you most of the way. The companies that win the next two quarters are the ones who stop trying to stretch it across the last mile, and put the right layer there instead. The platform was never the bottleneck. The readiness layer on top of it always was.

References

• Databricks — Curate an Effective Genie Space. 30-table limit per Genie Space; recommendation to aim for five or fewer; suggested approach for larger topics is to pre-join related tables into curated views.
• Coalesce — The Complete Guide to Databricks SQL Data Transformation. Business analysts cannot contribute directly; data engineering becomes order-takers; self-service stays limited.
• BARC — Databricks Data Intelligence Platform Reviews 2026. Business-user support and administrative complexity raised most often; only 16% report no significant issues; key-user support below category average.
• e6data — Databricks Cost Optimization at Scale 2026. Idle and inefficient compute as the single biggest source of lakehouse waste.
• Promethium — Enterprise Text-to-SQL Accuracy & the Spider 2.0 Results. Accuracy collapse on realistic enterprise schemas.
• MIT NANDA via Forbes — MIT Finds 95% of GenAI Pilots Fail Because Companies Avoid Friction. ~95% of generative AI pilots not delivering measurable P&L impact.