SAP’s Dremio acquisition gets me confused

Since 2025, I have been warning about SAP Catalogs' problem”, Dremio acquisition by SAP has made it even worse. I did not see this coming at all.

Since early 2024, SAP has told customers three distinct stories about where machine learning, federation, and analytics on SAP data should run. I know it because that is what I do for a living: I advise customers on their best strategy based on their needs, which are diverse. It's been hard because each story came with an architecture diagram, a partner ecosystem, and an investment ask.

Today, I am writing this post because I have personally explained each of these stories to customers, in order, with conviction. Each one was the official SAP messaging at the time it was given.

Chronologically

1. Until early 2025: HANA Cloud (PAL) is your only federated ML platform inside SAP.

Wether you run HANA or HANA Cloud, HANA federates remote data and runs machine learning execution and forecasting. It has been there for many years, using two libraries called the Embedded Predictive Analysis Library (PAL) and Automated Predictive Library (APL). The pitch: keep the data in SAP, push compute to where the data is, no need for an external lakehouse for SAP ML use cases. Be Lean, save money, your Data Engineer will have no problem using PAL and APL, Monte Carlo simulations.

2. Since SAP Databricks was announced, the analytical and ML platform has shifted. HANA Cloud is very expensive and runs on memory, so when data goes REALLY BIG, it's a big and expensive limitation to do all that on a monolitic memory engine, so for massive transactional workloads, and apply Spark, Databricks is a masterpiece analytical and ML engine that runs on top of the storage, no need to bring it to memory. Delta Tables are the open format, Delta Share is the zero-copy bridge mandatory for Databricks, and Unity Catalog is the governance layer that SAP needs to “communicate” to leverage this platform. Things start to get complicated, but SAP and Databricks invest a significant amount of money to make it easy for customers. From a customer perspective, this looks like a solid partnership from two reputable companies, and SAP Databricks being OEM makes it easy for SAP customers to avoid multiple contracts and be on SAP paper.

3. It got more complicated in October 2025: “BDC Connect extends the Delta architecture to Snowflake and BigQuery.” Partnerships are good, but BDC Connect for Snowflake (Delta Share + Horizon Catalog), BDC Connect for BigQuery (Delta Share + Dataplex). Breaks my engineer mind, and I blog about it; if the Delta-and-multiple-catalogs world becomes the official architecture, this is a Data Catalog nightmare that someone must handle, wether its SAP or its customers

[embed]What I learnt this week about SAP BDC Connect I am going to be honest, I am very intrigued about BDC Connect.medium.com

It was not the first time I wrote about Catalogs. Anyone who has been integrating SAP Data at scale (using Collibra, Atlan, or none of them, replicating, federating, or whatever) feels the pain.

So now, if I need to say BDC will be now Iceberg-native, governed by a Polaris-based open catalog going forward, for an engineer like me, blows my mind 🤯

When SAP saves data to FOS (Native storage layer), today, it's in Delta. Not Iceberg. There is no “FOS / BDC becomes an Apache Iceberg-native enterprise lakehouse, eliminating the need to move or convert data between formats.”

Customers were NOT ALLOWED to convert data between formats in FOS. It's pre-defined.

If the format pivots from Delta to Iceberg. The catalog pivots from Unity to Polaris. The federated SQL engine pivots from Databricks SQL to Dremio. That is a lot, it's a completely new architecture, it's a complete new Connector (and MCP servers, going forward). I don't know how they would have received this news at Databricks, but I am sure that if they invested their time and money… well, it's not the first time SAP does this.

Iceberg and Delta are not interchangeable formats with cosmetic differences.

They use fundamentally different catalog architectures. Delta uses a centralized catalog model — the catalog (Unity) is the source of truth, and Delta tables are governed by the catalog. The challenge with Unity is that it is largely a vendor-backed project (Databricks), but if you are an SAP customer, its Ok, because you already don't play by “open source” rules, you are already “vendor source,” so having Unity Catalog, which is robust, was reasonable. If you want governance across all those tools, that’s done within the SAP/Databricks ecosystem. Now, Iceberg is the opposite; it uses a decentralized catalog model — each Iceberg table carries its own metadata files (manifests, snapshots) on disk, and catalogs (Polaris, Nessie, Glue, etc.) are interchangeable pointers into those files via the Iceberg REST Catalog API. Essentially, Iceberg is open source at the almost “storage” layer. Completely opposite to BDC.

In Iceberg, the format is the source of truth, and the catalog is a discovery and governance layer on top, but it forms the Iceberg.

This is not a minor technical distinction. It changes who controls the data.

Delta + Unity = SAP controls governance.

Iceberg + Polaris = the data controls itself; the catalog is a pluggable view.

So when SAP spent 18 months telling customers “build your BDC architecture on Delta Share and Unity Catalog,” they were committing those customers to the SAP centralized-vendor-catalog model.

If SAP now says BDC is Iceberg-native with Polaris, as Yahoo says in this article , they are committing to a decentralized-open-format model. That is not BDC, these are architecturally opposed worldviews.

This is not an evolution of the architecture; to me, it's a reverse. FOS writing on Iceberg is not a “checkbox” to activate.

ML question — what actually replaces what?

Where does ML on SAP data run going forward?

On 1. said HANA Cloud (PAL/APL). On 2, I said Databricks because in BDC, data is in Delta Tables (MLflow, notebooks, Spark ML). But now, Dremio says, “I can execute queries on data saved on storage as soon as it's saved in Iceberg”…. What Iceberg? If data is in an Iceberg in BDC/FOS, why can't I run AWS Athena on top of that Iceberg? I don't require BDC Connect anymore.

Dremio is not an ML platform; it does not compete with Databricks. It competes with AWS Athena, it’s a query engine.

Every one of the stories above has a different answer to “where does the data live and who governs it.” None of them solved the underlying problem, which is:

how does an AI agent (or any consumer) reliably discover, access, and reason over SAP business data without picking sides in the HANA-vs-Delta-vs-Iceberg, Unity-vs-Polaris, Databricks-vs-Snowflake-vs-Dremio technicalities?

I have no answer right now, but one thing I know for certain is that the only architectural answer that is robust to SAP changing its mind every 12 months is a catalog-orchestration layer above the platform layer, exposed via MCP.

Maybe Collibra, Atlan, and Alation were just optional until now, but going forward, I believe they are going to be way more important for customer conversations.

By the way, if customers are already plugging AI Agents to Data (which I think if its not the case, it will be the case) MCP specifically is very important.

MCP abstracts the protocol of agent access from the implementation of the underlying catalog. Whether SAP’s authoritative catalog this quarter is Datasphere Catalog, Unity, Horizon, Dataplex, or Polaris — an MCP server in front of it presents a stable interface to agents. The architecture below can churn, but the agent contract above does not have to.

In the four-catalog world I described in October, every catalog had its own governance model, lineage representation, and access control. The only sustainable answer is an orchestration layer that federates governance across catalogs — reads from Polaris, Unity, Horizon, Dataplex, presents a unified semantic view, and enforces policies once.

Catalog orchestration is no longer a “nice to have.” Catalog orchestration is the only layer that gives customers continuity across SAP’s pivots.

What customers should actually do if they are committed to SAP Databricks?

If you committed to SAP Databricks as your BDC analytical engine, your investment is not lost, but the Delta/Unity layer has a competing technology that will make SAP accomodate or re-focus, so in the next 12–24 months, the half-life inside BDC is worth asking SAP for a clarifying roadmap for FOS, if customers will decide if data is stored in Delta (and then use BDC Connect) or in Iceberg (and then its open to consume).

If you bet on HANA Cloud ML for forecasting and predictive workloads, which looks like old technology (but it's what, to my surprise, SAP demoed during keynote Teched 2025), the path is technically still supported, but is going to lose narrative. PAL/APL inside HANA Cloud remains useful for straight embedded transactional ML, but for anything broader, plan for an Iceberg-fed agentic model instead, which is what Dremio does. Databricks as well, but to do it in Databricks, you had to save the data outside of HANA and run a separate engine. That might not be the case going forward.

Freshers, if you are starting fresh on BDC, I wonder if you can wait to build for Iceberg + Polaris + MCP from day one. skipping the Delta detour. Delta requires Multiple Catalog orchestration. Iceberg not so much, the catalog is in the format itself, not centralized.

One thing is clear. Treat Datasphere as your SAP business context layer (Replication Flow, ABAP CDS, semantic models) orchestrator.

At Sapphire 2026, I don't expect SAP to stand on stage and say “We got the BDC architecture wrong and we’re fixing it with Dremio.” The messaging will be that BDC is evolving and that all the previous investments compose. That this goes “On top”. But I don't see it that way; Delta and Iceberg do not compose cleanly. Unity and Polaris do not compose. Dremio is 0% Delta, 100% Polaris. Databricks and BDC Connect are 100% Delta.

By Author

Customers will win once you build a Business Semantic that works independent on which Catalog or Table format SAP runs on. If that is the case, then we have been “instructing” customers quite ineffectively last year on “what is Delta and why would you care, what is BDC Connect and why would you care”.

If the answer from SAP is, in SAP, we are above that, now you don't care, well, if you are Snowflake, Databricks, or Apache, you DO care. Microsoft Fabric cares, AWS Sagemaker or Athena cares about it. It matters.

Why caring? Because SAP is positioning Snowflake, SAP Databricks, Microsoft Fabric, or Google BigQuery as the engine for Zero Copy, the analytics platform chosen by the customer matters because the rest of the analytics might already be using Table Storage. The Protocol matters, the FOS matters, the Delta vs Iceberg vs in memory with HANA matters, because it matters to your analytics team, and matters to your CFO (once he sees the bill, depending on the architecture, Egress data or Spark query engines)

That is what people like me do for a living. We get pulled into a customer conversation, and we are asked about preserved semantics and zero-copy. Until yesterday, the answer was clear. That's the Delta mechanism, you gotta be prepared in Delta if you want to leverage Zero Copy, you have to know about SAP ORD and CSN, you can use the BDC MCP server that is going to help your Databricks, and put that in order.

This week, it all changes. Dremio fundamentally changes who has the privilege. If it's true that BDC becomes Iceberg-native, the FOS Object Store will speak an open table format that any compliant engine can read — Trino, Spark, Snowflake, Flink, BigQuery, Dremio itself. The Databricks-only privilege ends.

In October 2025, I described four catalogs and called the situation a governance nightmare. In November 2025, I described SAP being stuck on Delta while the world moved to Iceberg.

[embed]What I learnt this week about SAP Snowflake and BDC Connect for Snowflake. SAP announced this week two things: one is an OEM version of Snowflake, called SAP Snowflake, still lacking details…medium.com

Now, in May 2026, I tell you something: the architecture is moving toward Iceberg + Polaris + Dremio engine + Knowledge Graph as semantic enrichment is something that SAP will need to integrate, because it's not there today; today, there is something completely different. What its there is Datasphere doubles down as the SAP business context layer (semantic models, Replication Flow, ABAP CDS proximity) and the BDC prominence is a real thing, that SAP using Delta in FOS was a limitation factor they will try to focus away with Dremio, its very clear, but this is going to be a set of new architecture paradigm, connectors, MCP servers, catalogs and products that SAP customers will need to be aware of going forward.