Modern Power BI architecture choices for reporting on Azure Databricks: A performance benchmark for Power BI storage modes
Many enterprise Power BI semantic models use Azure Databricks as a data source. When building these models, developers and architects face an early and consequential decision: which storage mode to use. Cost, security, and ease of development and tuning all factor in — but report performance is probably the most important of them, because reports that are slow to load are one of the most common causes of end-user dissatisfaction.
In practice, that decision is often made on intuition rather than evidence. To help change that, we've published a new white paper, Modern Power BI Architecture Choices for Reporting on Azure Databricks, benchmarking four ways of serving the same Delta tables to a Power BI report:
-
Direct Lake on OneLake — over Delta tables in a Fabric lakehouse or warehouse
-
Direct Lake on mirrored Unity Catalog tables — shortcuts, no copy
-
DirectQuery — on a Databricks SQL warehouse
-
Composite Model on Databricks — DirectQuery combined with Import-mode aggregations
Figure: The four Power BI storage modes benchmarked to evaluate their impact on report performance and scalability.
What the results suggest: there's no universal winner — but there are clear patterns.
Direct Lake on OneLake performed well across the widest range of situations in this benchmark. It's highly competitive at smaller and mid-size volumes, and for the typical Power BI workload — where reports are used repeatedly throughout the day — it delivers interactive performance without extra modeling effort.
At the top end of the volume curve, the picture shifts. With billions of rows, a Composite Model with aggregations was the fastest and most consistent pattern, staying sub-100ms on queries the aggregation tables can resolve. The caveat is equally clear: that advantage doesn't extend to queries that fall through to the underlying DirectQuery source, so the payoff depends on how well your aggregations match real user behavior.
These are just the headline findings — the detailed results vary considerably by data volume, cache state, filter scenario, and query type. We'd encourage you to read the white paper for the full picture before deciding on a pattern.
One thing worth noting up front: this is a point-in-time comparison as of June/July 2026, and both platforms are moving quickly. It also measures the end-user query experience within Power BI, rather than raw database execution speed. Treat it as a guide for running your own testing, on your own data.
Explore the white paper for a full walkthrough of through each pattern in detail — the test setup, what was measured, and how results break down by data volume, cache state, and query type.
Visit the Power BI download center to access the paper and other related resources.
Source: This article is curated from Power BI Blog. Visit the original post for more details and official documentation.