Power BI Was Built as a Client. Stop Using It as a Foundation.

Microsoft wants to own your semantics. We built the universal layer that keeps them yours.

Power BI is a strong BI client. It was never an enterprise semantic layer, and the gap between those two jobs is now showing up as vendor risk. Microsoft has signaled that Power BI’s front end is designed around Power BI’s own models. No sanctioned Live connector to a third-party semantic layer is on the roadmap. In April 2026, BI compatibility mode was removed from the Power BI Azure Databricks connector with two days’ notice, and Databricks Metric Views dashboards went dark. That’s the operating reality for any company whose semantic foundation lives inside Power BI.

The pull doesn’t stop at the dashboard. Fabric IQ extends Power BI’s perimeter into the agent layer. Ontologies are generated, one click at a time, from existing Power BI semantic models, which means whatever drift and report-scoped definitions are in your dataset become the ground truth your agents reason against. And because Fabric IQ’s ontology bindings don’t support DirectQuery, getting full behavior against your Snowflake or Databricks warehouse pushes you toward Fabric Mirroring. That means paying Snowflake to read changes on one side, paying Fabric capacity to hold and query the copy on the other, and paying storage above the included allowance. Microsoft explicitly states that source-side row-level security must be reconfigured in the mirrored copy. Two systems to govern. Two systems to audit. One number to defend.

There’s a cleaner architecture. Author the semantic model once, in a neutral layer that speaks every protocol your stack already uses. Power BI gets DAX over XMLA. Excel gets MDX over XMLA. BI tools get native SQL pushed down to the data platform. Agents get MCP. Define your semantics. Choose where to compute your semantic queries. Choose your consumption tools.

Read the full brief

We’ve written the full case up as an architectural brief for data and analytics leaders weighing how far to lean into the Microsoft semantic stack. Authoring Enterprise Semantics Inside Power BI: Risks and Alternatives walks through six structural problems with modeling inside Power BI, the role each open protocol plays in a portable architecture, the Fabric IQ and Mirroring cost picture in detail, and a concrete migration path for teams already on the wrong foundation. It’s written to be useful inside a procurement conversation, an architecture review, or a board-level data strategy discussion. It doesn’t require committing to any single vendor to be useful, including ours.

The argument is simple: your semantics, your compute, your freedom of choice. Define it once. The engine renders it everywhere. The CFO and the Chief Data Officer get the same answer on the same Tuesday, from the same definition, regardless of which surface asked the question.

Power BI is welcome at that table. As a client.