Semantic modeling patterns with Power BI and Databricks

Databricks – the inventor of the Lakehouse architecture – has become a popular data platform that many organizations adopt. One of the more meaningful ways to leverage the data in Databricks is through visualization and reporting in Power BI. But how can we do this most effectively? 

Integration between Power BI and Databricks has significantly evolved over time. As a result, multiple integration patterns have emerged, each tailored to potentially different scenarios and use cases. This article provides an overview of some options to integrate Power BI with Databricks, with focus on building robust semantic models directly on the Databricks Lakehouse that you can use for reporting, dashboards, and querying data with AI experiences. 

The diagram shows the following approaches: 

1. Databricks SQL and Power BI Desktop
2. Publish to Power BI Service from Databricks, directly
3. Power BI task in Databricks workflows
4. Databricks, Tabular Editor, and Power BI

We'll explain these approaches in the rest of the article. 

Databricks SQL and Power BI Desktop

Most users begin their Power BI development journey with Power BI Desktop, which remains the most common starting point for building semantic models. A few years ago, Databricks introduced Databricks SQL that is designated to run BI workloads. If you're still using interactive clusters to connect Power BI to Databricks, switching to Databricks SQL warehouses can offer significant performance gains. 

This pattern is a great starting point because Power BI Desktop is easy to use and widely adopted, and Databricks SQL warehouses provide scalability, and are optimized for BI use cases. 

Despite its popularity, this approach has a few limitations: Firstly, except for configuring incremental refresh, Power BI Desktop does not support custom partitions in semantic models. Custom partitions are a technique for dividing tables into smaller, more manageable segments. This can be a limitation for large models, and it has several benefits, such as:  

• Faster refreshes: Partitioning can let you refresh multiple parts of a table at the same time. This allows parallel refresh (e.g., configuring MaxParallelismPerQuery), which can drastically reduce refresh duration. 

• Better resource management: You can leverage partitions for more efficient queries and manage these partitions separately, refreshing only the partitions that you need to, rather than the entire table. 

It is important not to confuse the partition in Databricks vs the partitioning in Power BI. Partitioning in Power BI happens in the semantic model, while partitioning in Databricks happens in the Lakehouse. This is partitioning Delta tables, the need of which has been replaced by liquid clustering. Liquid clustering can boost Power BI query performance when the cluster keys are common query predicates. Liquid clustering is to Databricks as v-ordering is to Fabric.

In summary, approach one involves creating and managing your semantic model from Power BI Desktop. While straightforward to get started with, there are several limitations. Power BI Desktop is not available for macOS, excluding Mac users from semantic model development. Furthermore, to unlock other advanced modeling capabilities, tools like Tabular Editor are needed (which we will cover later in this article). 

Pros: 

• Easy to get started with Power BI desktop, so adoption threshold is low. This pattern can serve as a starting point for your semantic modeling journey. 

Cons: 

• No custom partitions, not suitable for partitioning use cases beyond simply time-based incremental refresh. This is especially important for developers working on large semantic models to consider.  

• Mac users will need to do modeling via a Windows virtual machine to use Power BI Desktop. 

• Can be limited and/or slower for complex modeling tasks, so this option is not suitable for experienced developers, or those who are looking for automation and advanced modeling features. 

Best for: Desktop developers with simple/moderate modeling needs and no requirement for advanced partitioning or automation. 

Publish to Power BI Service from Databricks, directly

Databricks introduced Publish to Power BI Service last year – a web-based integration that connects a Databricks workspace to Power BI using Microsoft Entra ID. This feature allows users to publish a table or an entire schema directly from Databricks to a Power BI workspace, enabling quick data access in Power BI without needing Power BI Desktop. 

All modeling is performed in the Power BI Service web UI, which makes it accessible to Mac users and ideal for ad hoc data exploration. However, this feature is best suited for lightweight scenarios, as it currently lacks API support, which means you cannot use this functionality by calling a REST API endpoint. In addition, the modeling capabilities are limited compared to what's available in Power BI Desktop or external tools like Tabular Editor.

Pros:  

• The click-and-drop function makes it easy to get started with Databricks UI and Power BI Web UI. Once the connectivity between the two services is configured, the deployment only takes a few clicks. 

• Since the solution is web-based, Mac users have the same user experience as Windows users. 

• Good for data exploration of Databricks data in Power BI. If your use case is simply bringing some data from Databricks into Power BI and doing some quick ad hoc analysis, this is a great option. 

Cons:  

• Modeling capabilities are very limited since Power BI Web UI has limited modeling capabilities. This is thereby not suitable for use cases that requires more than basic modeling tasks. 

• No API support means operationalization of data modeling done through this feature is not possible. As a result, this is meant more for one-off exploration than for production data pipelines.

Best for: SQL analysts doing ad hoc data exploration.

Power BI task in Databricks workflows 

Announced in Q1 2025, the Power BI task in Databricks Workflows is an evolution of the "Publish to Power BI Service" feature. This enhancement allows Power BI to be configured as a task within Databricks workflows, enabling users to publish, update, and refresh Power BI semantic models in a fully orchestrated and automated way. 

The feature supports DirectQuery, Import, and Composite modes, and is available with Databricks Jobs API and Databricks Asset Bundles, making it well-suited for DevOps and CI/CD pipelines. While powerful for automation, it’s important to note that the feature is still in preview and does not include modeling capabilities – modelling must be performed in the Power BI Service Web UI, similar to the previous Publish to Power BI feature.

Pros:  

• Databricks Workflow built-in feature that comes with Job API and DABs support, which means you can extend your DevOps pipeline from just data engineering in Power BI to include the publishing of semantic model in Power BI.

• Possible to chain ingestion, data engineer, and publishing Power BI semantic models in a single pipeline in an orchestrated manner. 

Cons: 

• Like the previous pattern, modeling capabilities are very limited given Power BI Web UI’s lack of modeling capabilities. This is not suitable for developers that need to do some development on the semantic modeling beyond the basic tasks. 

• This feature was announced in FabCon 2025, still in Public Preview. Organizations that can't adopt preview features based on company policy will need to wait until it goes to GA. 

Best for: Data engineers owning semantic layer with very simple modeling needs. 

Databricks, Tabular Editor, and Power BI

This pattern stands apart from the others by introducing an external tool – Tabular Editor – into the architecture. Tabular Editor serves as a powerful bridge between Databricks and Power BI, enabling both advanced semantic modeling and DevOps workflows. With a native Databricks connector, Tabular Editor supports complex modeling scenarios and full automation of tasks such as deployment, version control, and scripting.  

This approach is ideal for teams looking to optimize and automate the full lifecycle of Power BI semantic models. However, it introduces additional tooling complexity, and since Tabular Editor is Windows-based, it excludes Mac users just like Power BI Desktop (as discussed earlier, in approach one). 

To dive deeper into modeling and automation features, visit Tabular Editor Learn. For DevOps integration patterns between Databricks and Power BI using Tabular Editor, check out my upcoming session at SQL Bits 2025: “Bridging DevOps Across Power BI and Databricks with Tabular Editor.”

Pros:  

• Offers more advanced features for managing complex models, which means you can build better models faster using Tabular Editor. 

• Advanced scripting and task automation for data modeling, which can help you improve productivity when working with semantic models. 

• Enables version control and parallel development for deployment, which makes team collaboration possible when working on the same semantic models.  

Cons:  

• Requires some familiarity with Tabular Editor and Power BI modeling concepts. If you are just getting started with Power BI and want to learn the basic of Tabular Editor, you can check out this beginner course on Tabular Editor Learn.  

• Requires setting up Tabular Editor and introducing one more component in the End-to-End Development. More components in the End-to-End pipeline means more complexity to manage, and you will need to set up the DevOps pipeline properly to orchestrate the End-to-End process.  

Best for: Advanced modellers who have needs for end-to-end DevOps, team collaboration, model optimization, and/or batch task automation.

In conclusion

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, where they create and manage their semantic model from the Windows application. While simple, this approach has limitations that can inhibit enterprise organizations with large models.
   
   
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 Power BI Service. Then, you build the model in the web. This approach can be suitable when users have Mac OS or simple modelling requirements, but the web modelling experience does not offer the same features or utility as alternatives.
   
   
3. Power BI task in Databricks workflows: With this approach, you can streamline and automate semantic model publishing from Databricks using Databricks workflows, but you still need to build the model in the Power BI service via the web. You can leverage more advanced CI/CD, but have the same limitations as Approach 2.
    
4. Databricks, Tabular Editor, and Power BI: With this approach, you use Tabular Editor to connect to Databricks and build/manage your semantic model, which you deploy to Power BI. Here, you can leverage all the productivity enhancements of Tabular Editor to ensure that your semantic model is tuned to perfection. However, developers need to know how to use Tabular Editor and deploy/manage models via XMLA read/write endpoints. 

Choosing the right approach depends on your scenario and needs! 

Are you attending SQLBits 2025? 

I am very excited to host a session at this year's SQLBits on the topic Bridging DevOps Across Power BI and Databricks with Tabular Editor. In that session, which takes place Friday 20 June at 12:20, I will cover how to connect Tabular Editor to Databricks, data modeling using Tabular Editor, and explain how to do DevOps for Power BI and Databricks with Tabular Editor, end-to-end.

Hope to see you at Bits!