In Short: A Mature Pairing With Three Good Patterns
Power BI over Azure Databricks is no longer an integration story with caveats; it is a mainstream production pattern with a first-class connector, Entra ID sign-in and multiple serving designs. The decisions that matter are the same three that decide every BI backend: how data reaches the model (import, DirectQuery, or Fabric's lake-side route), where security is enforced, and who owns the semantic layer.
This guide is the field version: what we deploy, and where each pattern earns its place.
Pattern 1: Import From a SQL Warehouse
The workhorse. A SQL warehouse serves scheduled refreshes; the semantic model imports conformed gold tables; users get the fastest possible visuals and the platform pays for compute only during refresh windows.
It fits whenever the business accepts a refresh cadence, which is more often than dashboards admit. Design notes: refresh from gold, never raw; use serverless warehouses so refresh spikes do not require an always-on cluster; and keep the model a proper star schema rather than importing the lake wholesale.
Pattern 2: DirectQuery for Size and Freshness
Where tables are too large to import or minutes matter, DirectQuery against a serverless warehouse holds up well - Photon made the difference here. The familiar disciplines decide the experience: measures that push down cleanly, no chatty visuals-per-page sprawl, aggregations for the hot paths, and warehouse autoscaling matched to the BI crowd's bursts.
Security deserves explicit design in this pattern: Unity Catalog row filters govern the source, model RLS governs report consumers, and you should decide which is authoritative for whom rather than configuring both by vibes.
Pattern 3: Publish From Unity Catalog, and the Fabric Route
Two newer options shorten the pipeline-to-report distance.
Publish to Power BI lets Databricks push Unity Catalog tables - relationships included - into a Power BI semantic model, with workflow tasks keeping the publication current as pipelines run. Engineering's catalog becomes BI's starting model instead of a screenshot in a handover document.
The Fabric route skips the warehouse in the serving path entirely: shortcuts or Unity Catalog mirroring surface the same Delta tables in OneLake, where Direct Lake semantic models read them natively. For organisations whose BI governance, Copilot ambitions and user base live in the Microsoft experience, this is increasingly the default we recommend: Databricks keeps engineering, Fabric keeps consumption.
Choosing, Without Theology
Import when cadence suffices; DirectQuery when size or freshness forces it; publish-to-Power-BI to keep model and catalog aligned; the Fabric route when the Microsoft side owns consumption. All four assume the same foundations - conformed gold, owned definitions, tested security - and none of them rescue an estate that skipped them. The connector was never the hard part; the modelling discipline was, and remains so whichever door the queries walk through.
Sources and Further Reading
- Connect Power BI to Azure Databricks
- Databricks SQL overview
- Mirroring Azure Databricks Unity Catalog in Fabric
Frequently asked
Through the native Azure Databricks connector, pointed at a SQL warehouse, with Microsoft Entra ID single sign-on. From there the standard choices apply: import data on a refresh schedule or query live with DirectQuery.
Import for classic dimensional reporting where an hourly or daily refresh satisfies the business: it is the fastest experience and cheapest to serve. DirectQuery where data is too large or must be current: pair it with a serverless SQL warehouse and disciplined modelling. Composite models mix both.
Databricks can publish tables and their relationships from Unity Catalog directly into a Power BI semantic model, and task types in workflows can keep that publication updated as part of the pipeline. It shortens the distance between engineering's tables and BI's model.
Both layers offer it: RLS in the Power BI model for report consumers, and Unity Catalog row filters at the source for anyone querying directly. Decide which layer is authoritative for which audience, and test both - the classic gap is a model RLS that direct SQL access walks around.
It is an alternative with real advantages for Microsoft-centric estates: shortcuts or Unity Catalog mirroring expose the same Delta tables to Direct Lake semantic models, no gateway or warehouse in the path. Estates already governing BI in Fabric often prefer it; estates centred on Databricks SQL are well served staying native.
