Power BI has three ways to reach Databricks. They look interchangeable in the UI; they are not interchangeable in performance or authoring semantics.
| Connector | Driver | 2026 status |
|---|---|---|
| Native "Azure Databricks" / "Databricks" Power Query connector | Chosen automatically | Default; right answer almost always |
| ADBC (Arrow Database Connectivity) | New columnar driver | Default under the hood for new connections |
| ODBC (Simba) | Legacy row-oriented | Still supported; do not author new against it |
The native connector
In Power BI Desktop, Get data → Databricks uses Microsoft's native connector. It handles OAuth, Unity Catalog navigation, partner-connect wiring, and selects the driver for you.
Use it unless you have a specific reason not to.
ADBC
ADBC is the Arrow-native connection layer adopted across the Apache ecosystem. Power BI shipped ADBC support in the Databricks connector in early 2026 and made it the default for new connections. Three gains matter:
- Lower connection latency. First-query time drops by multiple seconds.
- Faster metadata discovery. Listing catalogs, schemas, and columns is visibly snappier in the navigator.
- Dramatically reduced row transfer time on large result sets. ODBC deserializes row by row; ADBC streams Arrow columns. On 10M+ row DirectQuery visuals this is the difference between a 20-second render and a 3-second render.
Force ADBC explicitly when authoring M code:
Source = Databricks.Catalogs(
"adb-1234567.azuredatabricks.net",
"/sql/1.0/warehouses/abc123xyz",
[Implementation="2.0"]
)
Implementation="2.0" forces ADBC. The same toggle lives in File → Options → Preview features → Databricks ADBC.
Note
ADBC vs. ODBC is a driver-layer concern that a user interacts with at most once per connection. You do not need to teach it to report authors; you do need to ensure the organization's template connections are ADBC before rolling them out.
ODBC (legacy)
Existing reports on Simba ODBC keep working; there is no urgency to migrate them. New authoring should use ADBC.
If a published report slows down noticeably after a Power BI desktop or service upgrade, check the driver first. Occasionally a tenant-wide setting flips a connection back to ODBC; a connection that was fast yesterday is now slow today because it is quietly taking the row-deserialization path again.
The Databricks.Query trap
Custom SQL via Databricks.Query("select * from …") is the first thing seasoned SQL developers reach for. It works in Import mode.
Danger
Databricks.Query is not supported in DirectQuery. If you model against Databricks.Query and later flip a table to DirectQuery, the report does not error at authoring time but queries fail mysteriously at the service. Always model against Databricks.Catalogs(...) and let Power BI generate the SQL. Custom SQL belongs in a Databricks view or dbt model the connector reads like any other table.
Authentication
Three identity flows for Databricks connections:
| Flow | Use |
|---|---|
| OAuth (Entra ID) | Interactive user sessions, Power BI Desktop authoring |
| Service principal (M2M OAuth) | Power BI service, gateways, scheduled refresh, CI |
| Personal Access Token (PAT) | Banned for new work |
Service principals get scoped Unity Catalog grants (USE CATALOG, USE SCHEMA, SELECT). Rotate their credentials on the platform's cadence (automatic with Entra ID app registrations).
Warning
Power BI + Databricks integrations still show PAT examples in older tutorials. The 2026 Causeway policy is service principal + M2M OAuth for every service-to-service connection. PATs belong to individuals who leave; service principals do not.
Gateway considerations
Power BI Service is in Azure; Databricks can be anywhere. When Databricks is reachable over the public internet, Power BI connects directly. When it is not, you need a gateway.
Two gateway kinds:
- Power BI VNet Data Gateway (Azure-native): zero VMs, scales with capacity. Right answer on Azure.
- On-premises data gateway: a Windows VM you run. Required on AWS or when Databricks sits behind PrivateLink with no Azure networking.
For the on-premises gateway specifically:
- Gateway version v3000.270.10 or later is required for M2M OAuth to Databricks. Earlier versions silently fall back to less-preferred auth flows.
- Deploy the gateway on a VM with stable network to Databricks. Latency between gateway and warehouse is the floor on DirectQuery response time.
- Size the VM for refresh throughput: four vCPUs and 16 GB RAM for any non-trivial Import refresh.
AWS-specific
AWS shops hit a few extras:
- Traffic crosses clouds. Power BI Service (Azure) to Databricks (AWS) typically adds 20-80 ms per query depending on regions.
- PrivateLink and Power BI Service: the service cannot natively reach a PrivateLink-only endpoint. Options:
- On-premises data gateway in your AWS VPC, bridging Power BI Service to Databricks over PrivateLink.
- Public endpoint with IP allowlist.
- Inbound PrivateLink to performance services (Zerobus Ingest, Lakebase) is in preview and will tighten the cross-cloud story over time.
Connection quality checklist
Every production semantic model's Databricks connection should satisfy:
- [ ] ADBC driver (via
Implementation="2.0"or the preview feature). - [ ]
Databricks.Catalogs(...)source, notDatabricks.Query. - [ ] Service principal authentication (not PAT, not a named user).
- [ ] Gateway version v3000.270.10+ if on-premises.
- [ ] Pointing at a serverless SQL warehouse sized per compute types.
See also
- Storage modes — picking Import, DirectQuery, Dual, or Direct Lake.
- DirectQuery tuning — when you are locked into DirectQuery, how to make it fast.
- Model authoring standards — the connection conventions Causeway enforces in review.