Databricks and Power BI integration methods

 In most modern data platforms, Databricks serves as the ETL and data engineering powerhouse, transforming and preparing data at scale. Power BI provides the semantic layer, analytics, and visualization experience for business users.  

Databricks tables or views are typically imported into Power BI via connecting on a SQL warehouse. This is where the integration between these two tools typically stops. However, there are multiple ways to ingest Databricks data into Power BI or making the integration between these products much smoother and faster. 

In this article, we’ll explore the different ways Databricks can be integrated with Power BI, discuss where each pattern fits best, and highlight the advantages and disadvantages of each approach. Whether you’re building a new analytics platform or optimizing an existing one, understanding these patterns can help you make the right architectural decisions for scalability, governance, and skill level.

Prerequisites at a glance 

On the Databricks side, all four approaches run against pay-for-use compute (a SQL warehouse, or for metric views optionally a cluster) regardless of which pattern you pick. The Power BI side is where the license requirement actually changes. The table below provides a complete overview.  

Method	Power BI side	Databricks side
Databricks SQL & Power Bi Desktop	Premium Per User (PPU) or Fabric capactiy	SQL warehouse compute
Publish to Power BI service	Needs the XMLA endpoint, Fabric capacity, (legacy) Premium or PPU	SQL warehouse compute and Unity catalog CREATE/USE CONNECTION privilege
Power BI task in Databricks	Same as above, on target workspace	Databricks jobs compute + SQL warehouse
Unity Catalog Metric views	Same connector requirements as Desktop, but DirectQuery only	SQL warehouse, or a cluster on DBR 18.0+

Databricks SQL & Power BI Desktop 

The easiest and most common way to integrate Databricks and Power BI is connecting Power BI Desktop directly to a Databricks SQL warehouse using the Databricks connector. For most organisations, this is still the starting point.  

There are two ways to set up this connection. The fastest option is Partner Connect: in your Databricks workspace, under the SQL Warehouse tab, you can download a .pbids connection file. Opening this launches Power BI Desktop with the server hostname and HTTP path already filled in, which is great for getting started quickly. Partner Connect gives you the same authentication choices as a manual connection (personal access token, Microsoft Entra ID sign-in, or a Databricks service principal via OAuth M2M client credentials). What it does skip is the Advanced Options dialog (default catalog, query mode, and so on), and it only launches with Databricks as the initial data source. Nothing stops you from configuring those settings, or adding other data sources, once you’re in Power BI Desktop. 

The alternative is a manual connection in Power BI Desktop. Use the native Databricks connector and enter the server hostname and HTTP path, found on the Databricks SQL Warehouse connection details page. Here you can set a default Catalog and pick a data connectivity mode. For heavier workloads, the connector also supports writing a native SQL query directly against the warehouse. In that case, it’s best practice to define the query as a view in Databricks first and connect to the view, rather than embedding a long query in Power BI. 

For authentication, three options are available: a personal access token, Microsoft Entra ID sign-in using the user’s own credentials for SSO, or, since the May 2025 release of Power BI Desktop, OAuth machine-to-machine (M2M) using a Databricks service principal. The service principal method is the recommended option for anything that needs to be refreshed unattended on the Power BI service. 

The benefit of this approach is its simplicity. Any Power BI developer can set it up in minutes without help from a Databricks administrator. Because it authenticates through Unity Catalog, existing row- and column-level security defined in Databricks carry through automatically. 

Publish to Power BI Service from Databricks 

Another method of integration is to publish a semantic model from Databricks directly to the Power BI service.  For this to work, a Power BI connection in the Unity Catalog needs to be created. More information can be found here.  

Note that you must have a CREATE CONNECTION privilege in Unity Catalog to create the Power BI connection. If a Databricks Admin makes it, a user should have the USE CONNECTION privilege to use the connection. Furthermore, your data must sit in Unity Catalog and the target workspace needs a (legacy) Power BI Premium, Premium Per User, or Microsoft Fabric capacity with the XMLA endpoint set to Read/Write. Power BI Premium capacities are being phased out in favour of Fabric, so for new workspaces, Fabric capacity is the path forward. 

When your credentials are configured, you can publish tables and even full schemas as a semantic model straight to a Power BI workspace, right from the Catalog Explorer UI where every table and schema has a ‘publish to Power BI workspace’ option. When publishing, you choose the SQL warehouse, the query mode, the target Power BI workspace, and whether to create a new semantic model or update an existing one. If primary and foreign keys are defined on the underlying dimension and fact tables, Power BI automatically picks these up and adds the corresponding relationships to the semantic model, so there’s no need to redraw them by hand. 

That said, the model isn’t quite ready to use straight away: credentials for the semantic model still need to be configured on the Power BI service side, and an initial refresh must be triggered manually before any data shows up. From there, a regular refresh schedule can be configured like on any other semantic model. Because the whole flow runs through the Databricks and Power BI web interfaces, it works just as well for Mac users as for anyone on Windows, which is a real advantage given that Power BI Desktop itself only runs on Windows.  

The built-in web modelling experience directly in the Power BI service is lighter than Power BI Desktop when building things from scratch. However, once the model is published, you can connect to it via the XMLA endpoint from Tabular Editor (or Desktop’s Live Connect) to do more advanced modelling, as long as the workspace’s capacity supports XMLA read/write. The bigger limitation, at least until recently, is that there’s no API for the ‘Publish to Power BI workspace’ click itself. It stays a manual action in Catalog Explorer, so it can’t be scripted, scheduled, or wired into a CI/CD pipeline. Closing that gap is exactly what the Power BI task described in the next section is for. 

Power BI task in a Databricks workflow 

A third integration method is to refresh or publish Power BI semantic models directly from a Databricks workflow. The main use case is a semantic model refresh in an ETL. A Databricks workflow is a fully managed orchestrator for data analytics pipelines that is similar to Fabric or Azure data factory pipelines but lives entirely in Databricks. Here you can define tasks and the relationships that need to be run such as notebooks, SQL files, python scripts, Databricks pipelines and many more. Schedules & triggers, tags and job parameters can all be configured. One of the tasks that can be chosen is a Power BI task. This is typically selected after all the previous tasks are completed and a refresh of the Power BI semantic model needs to occur. The benefit of using this compared to an Azure data factory refresh of the semantic model is that it is a web API and this is cumbersome. Microsoft Fabric also allows a model refresh as part of the ETL. However, this is a full refresh and no customization is possible in the UI. The Databricks Power BI task is therefore a better alternative with more refresh types. 

Several fields in the task must be filled in. First, a SQL warehouse needs to be selected, not a Databricks Cluster, that won’t work.  Then, workspaces and their semantic models can be chosen. A first choice regarding the refresh type needs to be made. 

• Data refresh: Triggers a Power BI data refresh (queries the SQL warehouse and loads data into the model). No schema/metadata changes. Only works in Import mode. 

• Metadata refresh: Only updates schema, columns, comments, and PK/FK relationships in the semantic model. No data is queried from the warehouse. This works in Import & DirectQuery mode. 

• Metadata & data refresh: updates metadata and triggers a full data refresh. Shows up in Power BI refresh history. Import only. 

In a previous task version, a field was available to choose the Import or DirectQuery method. This option is no longer available. However, this can still be changed by adding storage_mode: IMPORT to the table configurations in the YAML editor of the task. 

Furthermore, there is the option to overwrite the existing model. This should be treated carefully because when checked, all metadata and data are fully overwritten. This option is not available when selecting a data refresh under the refresh type. Overwriting replaces the existing model entirely and can break the Power BI report as tables/columns can be deleted or renamed. The unchecked (default) option only appends new metadata such as new columns or tables, but the existing ones are untouched. In our experience, this option should be disabled.  

The final option is then to select the tables that need to be updated. An entire schema can be chosen or specific tables from the schema. Note that when selecting a schema, all underlying tables will be published to the semantic model in Power BI. Be careful when selecting this option! Because if you select a subset of tables and you have selected the overwrite option, only the (meta)data of those tables will be updated. Other tables of your model will be deleted. It is therefore recommended to check the output of each of these settings when using the Power BI task in a Databricks job. 

As per our experience, the best setting is to enable a data refresh. This will keep the state of the Power BI report intact and not make any metadata changes to a report in production. Make sure that a local version of the pbix file is stored somewhere because when changes occur to the metadata, the file can’t be downloaded from the Power BI service anymore. 

Databricks recommends using an Azure Databricks service principal to be the Run as identity on the task, as is the best practice for production environments anyway. This service principal will need access to the Databricks schema, tables, Power BI connection, SQL warehouse and the Fabric workspace as well. 

The benefit of this approach is that a Power BI refresh can be run immediately after the ETL process of the job has been completed. This makes the process from ingestion to publishing much smoother. Given that this feature comes with job API and DAB’s support, it means that it can become part of the CI/CD pipelines in Azure Devops. 

The disadvantage is that when selecting certain options, it can overwrite the entire model, making it error prone. Users need to check the settings properly and investigate before using this in production environments.  

Unity Catalog Metric Views 

A final method of integration, which at the time of writing this blogpost is in Beta and experiences some difficulties when integrating them with Power BI, is to create Unity Catalog Metric Views in Databricks and convert them to a Power BI semantic model. Databricks describes Metric Views as: 

Provide a centralized way to define and manage consistent, reusable, and governed core business metrics 

Databricks introduced Metric Views in 2025 to solve a common problem in organizations. Gold medallion tables are created using best practices and build for business needs. However, there is often a large extra layer of requirements imbedded into a Power BI report where business users or IT create extra KPIs, create custom measures, or apply filters to the report. This results in different outputs for the same measure. Databricks tries to solve this issue with Metric Views.  

Metric Views allow users to build an entire data model in Databricks. This is done by combining all tables needed for a report, creating the dimensions and facts, applying the correct filters only once for the entire organization, and creating business metrics correctly.  

Metric views can be created using YAML, SQL or via the UI (preview). The figure below shows that Metric Views are built on the assets in Unity Catalog. 

The idea of a Metric View is to create a data model in Databricks. It is recommended to start from the fact table and then create joins for all the dimension tables. Next, the measures can be created as they are aggregated calculations. It is very important to specify the aggregation of the measure within the Metric View as this defines the result that the metric view will return to Power BI when being queried. Once created, the YAML file can look like this: 

Query a Metric View 

Metric views can be queried like standard views from within a SQL editor connected to a SQL warehouse. However, there is a difference when it comes to the measures. Since the distinction is made between measures and dimensions in the Metric View, all measures should be queried with the MEASURE () function. Writing a query with SUM () or any other aggregation function for a measure will result in a failure. The measure function is used because the aggregation is already defined inside the metric view. It inherits the definition of the aggregation from the Metric View definition and returns the measure column aggregated from the values of a group. 

To query a metric view, the syntax below can be used: 

Note that filtering is also possible. To query the metric views with other tables, the Metric View query needs to be wrapped in a CTE. 

Query a Metric View in Power BI 

Once a Metric View is created, Power BI simply serves as a visualization layer. There is no longer a need to define filters. To work with Metric Views in Power BI, Power BI needs to use the new ADBC driver, a desktop version later than February 2026 with the BI compatibility mode enabled. The metric view then appears as one table in the report. It is still best practice to create explicit measures. This can simply be done by doing SUM(measure) of the metric view, as Power BI sends the query to Databricks and it automatically translates it to the measure definition. 

However, Microsoft has recently decided to remove the BI compatibility mode option from the Azure Databricks connector in Power BI:

Removing this option made it no longer possible to query metric views from Power BI for a while. Reports using this connecter option no longer functioned. At the time of writing this blogpost, the feature was again in Beta mode.  

To enable the BI compatibility mode again, instead of selecting this as an option in figure 7, the following SQL commands need to be run at the start of a session. 

• SQL Warehouse: 

SET metric_view_bi_compatibility_mode = true; 

• Cluster: 

SET spark.databricks.sql.metricView.bi.compatibilityMode.enabled = true; 

The advantages of Metric Views are that they allow to centralize the business logic and data model in one place. This avoids duplicating logic in Databricks and Power BI and allows that the logic is defined in one place, allowing all users to look at the numbers with the same set of filters and creation methods. 

The disadvantage is that there are certain limitations. At the time when BI compatibility mode was still enabled, Microsoft advised using SUM for every measure in Power BI. This can be very confusing. Other limitations were that grand totals might display unexpected values, measure could not be used as dimensional values (e.g. as slicer) and that Metric Views measures only supported SUM, count, average, min and max. It is also best practice to include only one Metric View in Power BI, which can be very confusing if it is a very large data model with multiple fact tables. 

Closing 

In summary, there are several different approaches to set up a semantic model that uses data from Databricks: 

1. Databricks SQL and Power BI Desktop: With this approach, users connect to Databricks SQL from Power BI Desktop. This is the most common and simple method. This approach is straightforward and allows for fast analysis and results. 

2. Publish to Power BI Service from Databricks, directly: With this approach, you create the semantic model by publishing tables from the Databricks UI to the Power BI Service. Then, you build the model in the web. This approach can be suitable when users have macOS or simple modelling requirements, for heavier modelling, connect Tabular Editor via the XMLA endpoint once it’s published. 

3. Power BI task in Databricks workflows: With this approach, you can make the integration between the ETL process in Databricks and the refresh of the Power BI semantic models much faster. There are multiple options to choose from as how the model needs to be updated but can have some difficulties and limitations. 

4. Unity Catalog metric view: This has great potential to allow the data model and all the measures to be created in a single place. There is no longer need to add complex logic in Power BI reports. However, it is not fully integrated with Power BI as the connector has been disabled and is currently in Beta. Once fully integrated, it can have large impact on organisations with large volumes of data. 

Written by

Maarten De Court and Tibo Quinteyn are Microsoft analytics consultants with a passion for data visualization and engineering. Both have completed several projects as analytics engineers and Power BI analysts. They work daily with technologies such as Azure data Factory, Power BI and Databricks. Maarten and Tibo love to create powerful reports for our customers and help them in any way they can. Do not hesitate to reach out to them if you have any questions or would simply like to contact them.