The Dremio you chose is no more. The product still runs, for now, but the company has been acquired by SAP. Like any acquisition, the independent vendor you built your data strategy around now no longer exists in its original form, and that has consequences. Specifically, it leaves every current Dremio customer with a choice to make, and we believe strongly that Starburst should be a part of every current and prospective Dremio customer’s solution to that problem.
How Starburst sees the situation
First, let’s be plain about where we stand. Starburst has always competed with Dremio, and there have always been compelling reasons to choose Starburst over Dremio. After the acquisition, that competitive advantage has now become far stronger. There has never been a better moment to make the move, and we believe it’s the right call for nearly every Dremio customer now that SAP has the reins.
We know this because we’ve been working in this space and know Dremio’s customers just as well as our own. We’ve worked alongside both platforms and sat across from the teams choosing between them. We know where Dremio is genuinely good, where it falls down, and what this acquisition actually changes. We are experts in solving analytics and AI problems in the data space, which is the part that should matter most to you right now.
That’s the value of reading this, whatever you ultimately decide.
Dremio attempted to solve a real problem
Let’s give credit where credit is due. Dremio’s founders came out of MapR and built Apache Drill. They understood analytics at scale in distributed environments, and they understood query engines, specifically the value of SQL over legacy Hadoop, and the importance of Apache Iceberg for the modern lakehouse. They also built a caching layer called “reflections” and understood where caching can boost performance, and why that matters. If you wanted to query cloud storage without first hauling everything into a warehouse, Dremio earned a spot on the shortlist.
It also carried real limitations, and they were never secrets. Federation breadth. Concurrency at scale. Governance depth. The sheer amount of hand-tuning needed to hit BI performance. Those were fair things to weigh against the alternatives, the way you’d weigh any platform. But here’s the part that matters today: none of that is what changed. The engine is the same engine it was last month. What changed is who controls its future, and that should be the center of your decision now.
Three things that change with Dremio’s acquisition
And that brings us to three key points on the Dremio acquisition, each one of them answered by Starburst.
1. The roadmap now belongs to SAP
Until now, Dremio has set its own priorities, driven by competition in the lakehouse market and by what its customers asked for. That ends when the deal closes. SAP has its own portfolio, its own cloud, and every reason to pull customers toward consolidating on SAP over time. This isn’t a knock on SAP. It’s simply what all acquisitions do, every time.
So the features Dremio was building on its own now have to fight for budget inside a far larger company, against priorities that have nothing to do with you. The engineering that was aimed at the gaps Dremio customers actually care about is now up for reallocation. If you’re building toward agentic workloads, that’s not a theoretical worry, but a very real production roadblock, and a critical one at that.
Do the gaps you’re living with today get fixed, or do they sit untouched while the teams get absorbed into integration work?
AI means that all of this lands harder than it would have three years ago. A data platform for AI agents isn’t a six-month decision you can quietly reverse next year. It’s a multi-year architectural commitment. It determines what your agents can reach, how consistently they reason, and whether they hold up under production load. Committing to that on a platform mid-acquisition means betting years of your architecture on a roadmap you can’t see, owned by a company whose interests aren’t yours.
2. The independence story is harder to tell, and that means vendor lock-in
Plenty of teams chose Dremio for one reason above all. It wasn’t a giant proprietary vendor, and it didn’t perpetuate the problem of vendor lock-in to the extent large players like SAP always have. This meant open formats, neutrality, and no one pressuring you to consolidate.
All of that has now changed with SAP now firmly in charge.
SAP is one of the largest proprietary software companies on earth, with every financial incentive to move customers onto its own stack over time. SAP says it will continue Dremio’s Iceberg and Polaris work, and we’ll take that at face value. But sit with what actually happened here. A large share of Dremio customers bought in on the logic of “we picked this because it isn’t a vendor like SAP,” and that decision has now been reversed for them, by someone else, without their input. If independence was your reason, that reason is now gone. Portability was always the point, and portability is exactly what’s now in someone else’s hands.
3. Dremio’s underlying architecture has inherent limitations that can’t be solved
Dremio itself was stalling, and the reasons were architectural. Even before the acquisition, Dremio had known limits at the engine level, and concurrency was the loudest of them. Push concurrency up on large datasets and users hit memory errors and instability; standardized testing has shown the engine struggling to finish queries at a concurrency of just two or more on large datasets. These aren’t roadmap items waiting their turn. They’re architectural faults. Acquisitions don’t rearchitect engines, and SAP, which already owns competing data products, has little reason to tear down and rebuild Dremio’s execution layer to fix them.
For agentic workloads, that limit moves from footnote to dealbreaker. AI agents don’t run one query at a time. They fan out parallel requests across sources, so the concurrency ceiling that was a minor irritation for a BI team becomes a wall the moment agents are the primary workload.
Then there’s the question of how Dremio reaches data outside the lake, which is a deeper problem than it sounds. Dremio’s approach, based on their Reflections feature, relies on cached data by materializing query results internally. That’s how Dremio’s architectural approach to federation works at a technological level. Starburst also recommends caching for federation but that’s where the differences end. Whereas Dremio’s approach requires caching, Starburst gives you the choice. If it makes sense to cache, you can (often it does). If it makes more sense to access your data using federation without caching, you can do that too. The difference comes around scaling. Dremio’s approach is fine, but it doesn’t give you the choice and the scalability of Starburst’s solution. For agents that need a current, consistent picture of your entire data estate, that’s a real constraint, and a new owner doesn’t make it go away.
The governance gap is just as serious, and this is where the contrast with Starburst gets concrete. Dremio’s semantic layer names and organizes data, but it stops short of enforcing business rules, definitions, glossary terms, entity relationships, taxonomies, and ontologies in a governed, productized way. Without enforcement, two agents can draw two different conclusions from the same data, and nothing in the platform stops them. The Starburst Context Layer was built for exactly this. It packages metadata, business logic, and access policy into a single enforcement layer that every query passes through, whether it comes from an analyst at their desk or an agent running at 3am.
If you’re currently on Dremio
If you’re a current Dremio customer, you’re facing a crossroads ahead, and that comes with choices. We’re not here to tell you to run away overnight, at least not without contemplating it first. If Dremio’s core capabilities fit your use case, particularly SQL analytics on a consolidated data lakehouse that you own, with limited need for broad federation or the scale and performance required by AI, the engine still works, and the acquisition may not change your day-to-day much in the near term.
But the acquisition raises serious questions about the future direction of Dremio that are highly likely to impact customers in ways that will create real problems ahead for many companies. We see it every day, and this problem is only going to get worse.
What we’d suggest
Be honest about where the platform has frustrated you, and use this moment to ask whether those frustrations are likely to get better or worse under new ownership. The deal closes in Q3 2026, which means there’s still a window to run a clean evaluation before post-merger complexity sets in, before SAP reprices the product, and before switching costs compound further.
Consider governance
If governance and AI readiness are on your radar, it’s worth asking honestly whether a semantic layer that decorates data but doesn’t enforce business rules and context across agents is going to get you where you need to go. That question has a direct answer. Starburst’s Context Layer enforces those rules at the platform level, so your AI agents aren’t just finding the right data, they’re interpreting it consistently every time.
If you’re a new customer evaluating Dremio right now
What should you do if you’re evaluating Dremio right now? Our honest advice is to expand your evaluation before committing. Committing to a platform mid-acquisition means accepting contract terms, support structures, and a roadmap that are all subject to change as SAP integrates its new acquisition.
The strategic timing matters too. Agentic workloads are moving from pilot to production, and the data platform decisions made over the next few months will shape what’s possible for years. A platform designed for data lake acceleration and one designed for the concurrency, governance, and federation demands of AI agents are genuinely different things. Worth understanding that difference before you’re committed.
One question worth asking of any platform you’re evaluating. How does your Context Layer work? Specifically, what happens when two different AI agents query the same dataset and apply different business logic? If the answer is anything other than “the platform enforces a single consistent interpretation,” you have your answer.
What Starburst brings to this conversation
Starburst has the answers to these problems. It was built by the creators of the open source Trino, and offers a massively parallel distributed SQL engine purpose-built from the ground up for federated, multi-source workloads at enterprise scale. Concurrency under real production conditions is a first-class design constraint for us, not something we’re still working on.
The Starburst Context Layer is the most important component for teams thinking about agentic workloads. It’s not just a semantic catalog. We provide business meaning by packaging elements such as metadata, business logic, and role-based access policies into a unified enforcement layer that every query runs through. When an AI agent queries your data through Starburst, it’s not just finding the right tables, it’s operating under the same business rules and constraints as every other agent and analyst on the platform. That’s what trustworthy AI output actually requires.
Combined with native MCP server support and AIDA, Starburst is designed as a foundation for agentic data architectures, not adapting to them after the fact.
Optionality and choice matter too. Starburst is built on open standards, Trino is fully open source, and our architecture is designed so you’re never dependent on a single vendor’s continued investment to reach your data. You can run Starburst on any cloud platform, on-premises, or in a hybrid setup. Your data stays where it is. We think that kind of flexibility is going to matter more, not less, as AI workloads expand across the enterprise.
And our roadmap is ours. For organizations that picked Dremio because of its independence, that matters a lot right now.
If you’re on Dremio and want to understand what a migration path looks like, or you’re still in evaluation and want a real comparison, we’re happy to have that conversation.
