This is part 3 of 3 in a series where I take you through working with Metric Views.
Part 1: Introduction to Metric Views
Part 2: Metric Views and the Databricks platform (AI/BI Dashboards, Genie, etc.)
Part 3: Metric Views with Power BI and Tabular Editor
Not all semantic models are created equally
While a semantic model is a general concept that can be applied across a lot of different systems, I think it is no coincidence that Microsoft uses this exact term in Power BI to describe their models that are underpinning their reporting capabilities. As a result of this, people might associate the Semantic Model directly with Power BI for this reason, but as described in Part 1, we consider Metric Views to be a Semantic Model of its own as well.
In order to understand a bit about how and why things work the way they do, I think it might be a good idea to highlight some core concepts of Semantic Models, and how they work a little different between Databricks and Power BI.
Different models, same purpose
In my mind, a Semantic Model in Power BI are synonymous with a star-schema model. This is mainly due to the fact that the Power BI engine is designed around the star-schema, which means that it evaluates queries faster when the model is designed like this. When loaded into the semantic model, a star schema preserves each of the tables on their own.
In contrast to the star schema, a Databricks Metric View resembles more of a One-Big-Table style of semantic model. So even though we have facts and dimensions stored in separate tables, the Metric View itself is defined as a single view. This does introduce some issues, such as what to do in the case of a multi-fact model, or how to solve different granularities such as time. That being said, I do expect the Metric View to evolve to possibly handle some of these cases in the future.
For more details on the different types of Semantic Models, and their pros/cons I recommend this article by Kurt Buhler, written for Tabular Editor. This is centered around Power BI, but the general concepts are applicable across different BI tools.
Loading Metric Views in Power BI - Natively
Databricks Metric Views provide a unified semantic layer that can be queried via SQL. We have dimensions, measures and even some nice metadata descriptions, type hints and similar resources defined. Therefore, you might have the same idea as me.
We should be able to use the Metric View as the source for a Power BI report directly
With my complete naive and optimistic approach, I went ahead hoping that at least some of the model could be loaded and used as it was defined in Databricks. Well, unfortunately that was not at all the case. In fact, if you try to setup a Power BI model querying a Metric View using the native Databricks connector, pointing directly as your Metric View, you will not even be able to get anywhere. You will instead be met with the below error message.
In short, the above error tells you that in order to query a Metric View in SQL, you need to use the MEASURE() reference in each of the defined measures. Honestly, this makes sense, since it is the same approach you need when querying the Metric View inside of Databricks' own platform.
Here, I have added a short video shared by Databricks, where Simon Whiteley demonstrates exactly how a SQL Query of Metric Views actually works in practice.
Alternative approaches and workarounds
Alright, so since there is no native support, and it unfortunately does not exist on any roadmaps yet, I was wondering if we can do something else to actually leverage the definitions we have already created. The obvious solution is of course to lean into the Databricks native AI/BI dashboards as described in Part 2, but I also know that some companies are so heavily invested in Power BI that this would not be a viable approach, at least not in the short-term.
So I set out to test some workarounds. I am not aiming for this to be the perfect solution, so to be honest, I have fairly low expectations of anything actually working dynamically in terms of measure evaluation. I know that this is honestly not very useful when comparing to a DAX measure that is automatically evaluated at the granularity reflected, but let's see if we can work some magic.
Load to Power BI using SQL Query
While this might not be the most elegant of solutions, and you do end up losing quite a lot of the underlying logic of the Metric View itself, you do have the possibility of loading the Metric View using a SQL Query. This can be done in one of two ways, both of which are not that elegant:
Create a View on top of your Metric View (I know - this sounds dumb). In the view, the measures of the Metric View need to be referenced as MEASURE(measure 1) as 'measure 1' while the dimensions can be referenced directly by name.
Create a SQL query against Databricks directly. When setting up your Databricks connection, use a SQL query and write up the same definition as you would for the above view. Same concept, but you do not get an additional object inside of Databricks - instead you get a SQL query that lives inside your M partition.
Both of these approaches allows you to load the columns correctly to Power BI, however you are essentially left with a regular view, with no annotations, metadata or measure definitions.
None of these approaches actually achieve any benefit in having the Metric View. They would both work just as well by just using a regular View from the beginning - or even better - by loading the fact and dimensions from tables/views separately and defining your model inside of Tabular Editor (or Power BI Desktop). With the correct metadata in Unity Catalog, you would even get the Relationships defined automatically. Check out this article (and the rest of the series), written by 💀 Johnny Winter 💀 for some great tips and tricks.
Tabular Editors Semantic Bridge:
In November 2025, Greg Baldini from Tabular Editor went on the Explicit Measures Podcast to discuss their new MVP feature called the Semantic Bridge that they are working on alongside Advancing Analytics. The Semantic Bridge introduction and discussions starts at around minute 22:00 - but honestly the whole thing is really interesting.
This feature is meant to work across multiple semantic layers, and might be the missing link that can actually enable us to work with Metric Views in Power BI. While this is still in its early stages, I found the discussions around how to work across different formats and syntax really interesting and I can't wait to see what we can do with this feature in the future.
There will be a Bonus Episode to this series with more details on the Semantic Bridge specifically!
Conclusions
No Native Integration (Yet): Power BI does not natively support Databricks Metric Views. While the Databricks connector allows listing them from Unity Catalog, it cannot query them directly due to the required use of MEASURE() and GROUP BY logic that Power BI does not generate automatically. At this stage, Metric Views are most useful within the Databricks environment itself. Native AI/BI dashboards, and tools like Genie natively understand and correctly interpret Metric Views with no workarounds
SQL Workarounds Require Redefinition: The only functional workaround today is to write custom SQL queries in Databricks that explicitly call MEASURE() and expose the result as a view or table. These can then be imported into Power BI. However, this approach redefines the logic of the Metric View, weakening the promise of a single source of truth and also requires you to re-define your measures as DAX on the back of the integration.
Tabular Editor & Semantic Bridge: This might be the short term solution to cross-integration between the two platforms that allows us to translate one to the other and vice-versa, however it is still not a direct connection.
The Community is asking for more: There is growing demand for a native Power BI integration. Want to support it yourself, then check out this Microsoft Fabric community idea.
If you are really deep into Databricks already, it might be worth considering if the time has come to move your Analytics and Dashboards from Power BI into Databricks. But that's a topic for another day!
