Microsoft started a semantic war with Databricks. The next front is AI. Google customers need a semantic strategy to stay free on both.
Microsoft just killed the connector that let Power BI read Databricks’ business metrics. This was the opening salvo in a vendor war to control your data semantics. Databricks fired back, telling customers caught in the crossfire to either move their BI workloads to Databricks AI/BI or ask Microsoft to reinstate the feature. Neither is a good option. Chris Webb, a Principal Program Manager on Microsoft’s Fabric Customer Advisory Team, doubled down, writing:
“Microsoft has no plans to make Power BI’s front end work properly with anything other than its own semantic models.”
A vast majority of Google Cloud customers are Microsoft customers. Microsoft 365 is in 4 of 5 Fortune 500 companies, and 70% of the Fortune 500 have deployed Microsoft 365 Copilot on top of it (Datastudios.org research, 2025). Microsoft’s new policy means Looker metrics, Gemini grounding, and the Next ’26 agentic BI roadmap won’t work properly inside Power BI or Excel for almost any large enterprise
Why Semantic Wars Are Raging
Semantic wars are raging because whoever owns your business definitions owns the accuracy of every AI, BI, and SaaS computation in the enterprise. AtScale’s Dave Mariani calls it the two-numbers problem:
“Finance reports Revenue as $10.2M in Power BI, Marketing shows $10.4M in Tableau, AI copilot surfaces $9.8M in Slack. Which number do you bring to the board meeting?”
That’s the moment every CFO loses trust in the data, and every AI agent is tarnished by that distrust.
The Technology Behind the Semantic Wars
Google customers are just as vulnerable as Databricks customers, and the way out is the standards and protocols Microsoft actually supports. Unfortunately, Google customers are just as vulnerable as Databricks customers. The Looker–Power BI Connector is DirectQuery only: Power BI generates Power Query M expressions that the Looker API translates into live queries. This is the exact pattern Microsoft just said it won’t support. Excel has no native Looker path. A LookML metric does not arrive in an Excel PivotTable as a governed measure.
There is a neutral path. Power BI speaks DAX. Excel PivotTables speak MDX. Both travel over XMLA, the open Analysis Services protocol. These technologies are a standards-based approach to independence. AtScale supports full XMLA emulation, native DAX, and native MDX. Power BI connects through Get Data > Analysis Services > Connect Live. Excel renders the model as a real OLAP PivotTable with CUBE functions. No driver, no add-in, no custom connector. AtScale and Microsoft jointly developed the DAX connector that enables this.
This is the supported, neutral path to independence, and it works for the entire analytics technology surface.
The Next Front: Whoever Owns Your Semantics Owns Your AI
The semantic wars are not only about BI and Excel. The same war is brewing over AI. Gemini, Microsoft Copilot, and every enterprise agent platform need a semantic layer to return accurate answers, and each vendor is racing to make its own the only one their tools respect. The independence battle is about to spill over from your BI choices into your AI choices.
AtScale: The Demilitarized Zone for Your Semantics
Google Cloud customers don’t have to be in this fight. The solution is a universal, standards-based semantic layer owned by the customer. AtScale provides that layer. You define your metrics once. Serve them into Gemini, Claude, Power BI, Excel, Looker, and Tableau. Compute them in Snowflake, Databricks, BigQuery, or Spark. Any Iceberg-based compute engine. And whatever comes next, based on open standards that no platform can revoke.
With AtScale, the customer owns their technology choices, their business definitions, and the accuracy of every number that flows out of them. Let Microsoft, Google, and Databricks fight to be your analytics tool and compute provider of choice.
Just don’t let them control what your numbers mean.
SHARE
Guide: How to Choose a Semantic Layer