The quick answer: Power BI is moving its Databricks connector from the legacy Simba Spark ODBC driver to the Databricks ADBC driver. Microsoft’s plan flips the default in phases starting October 2026 and starts removing ODBC from the service in early 2027. Audit pinned connections, gateway refreshes and service principal credentials now.
This summer I handed a client’s silver and gold tables to their Power BI team. The lakehouse was clean. Within weeks, the KPI in the board deck no longer matched the KPI on the dashboard.
Nobody had broken anything. The same metric lived in three places: a DAX measure, a SQL query behind the deck and a gold view. Each copy drifted a little.
I’ve spent more than 30 years implementing enterprise systems, and the lesson repeats. The weak point is rarely the warehouse. It is the handoff between platforms.
Microsoft’s driver change puts that handoff back on your desk. Here is what changes, what breaks and what to check, in order.
What changed in October 2026 for Power BI on Databricks?
Power BI is retiring the Simba Spark ODBC driver it embeds in the Databricks and Azure Databricks connectors. The replacement is the Databricks ADBC driver, built on Apache Arrow.
Microsoft’s ODBC to ADBC transition guide calls ADBC especially efficient at fetching large datasets, with minimal overhead and no serialization or copying. That is the core of Apache Arrow columnar analytics: Arrow moves columnar batches instead of converting results row by row.
A tenant setting controls the switch. Microsoft’s plan turns that setting on by default in phases, starting October 2026. Workspace admins can override it for side-by-side testing.
Here is the detail most teams miss. In the service, any connection that doesn’t pin a driver follows the tenant default the moment it flips. Your existing semantic models can change drivers without anyone touching them.
Power BI Desktop works differently. Existing queries stay on the driver they were built with. To move one to ADBC, Microsoft says to delete the query, re-add the source and re-select the fields.
When does the ODBC driver leave Power BI?
Microsoft lists these as planned dates, subject to rollout readiness:
- October 2026: the tenant default begins switching to ADBC in phases.
- Early Q1 2027: ODBC drivers begin leaving the Power BI service. Staying on ODBC after that requires an on-premises data gateway.
- Spring 2027: the ODBC drivers stop shipping with Power BI Desktop and the gateway.
The gateway buys time. It doesn’t let you opt out. Once new gateway installs drop ODBC, gateways pinned to older releases eventually fall out of support.
Microsoft’s own audit tool flags one case as “will fail.” That is a model that pins ODBC and has no gateway binding. At cutover, its refresh stops.
How do ODBC and ADBC compare on Databricks?
| Item | Embedded ODBC (Simba Spark) | Databricks ADBC |
|---|---|---|
| Data transfer | Results pass through the ODBC interface | Arrow columnar batches, no serialization or copying |
| How it gets selected | Implementation=”1.0″, or unpinned with the setting off | Implementation=”2.0″, or unpinned with the setting on |
| Gateway-routed refresh | Stays on ODBC through cutover | Not used; test through a cloud connection |
| Power BI service | Removal planned from early Q1 2027 | Default in phases from October 2026 |
| Power BI Desktop | Planned to stop shipping in spring 2027 | Used by new queries in the current release |
Source: Microsoft Learn, Transition from ODBC to ADBC drivers in Power BI and Microsoft Fabric.
What breaks in a Power BI ADBC migration?
Pinned and hand-built connection strings
Any M query with Implementation="1.0" ignores the tenant and workspace defaults. Remove the pin, or the refresh fails at cutover unless a gateway is bound.
Hand-built DSN strings are the second trap. Microsoft notes that ADBC doesn’t consume a raw DSN string verbatim. Test those models in a copy before you touch production.
Custom M code and native SQL
Many models carry hand-tuned M code or native SQL written years ago against the ODBC path. Treat those queries as untested until you have checked them on ADBC.
Copy the model, switch the copy to ADBC and compare it with production table by table. Check data types, null handling and row counts on every query that passes native SQL. When you find a difference, fix it in the gold layer view, not with another layer of M code.
Gateway configurations
Gateway-routed refreshes keep using the ODBC driver bundled with the gateway. A test that runs through a gateway proves nothing about ADBC. Validate with a cloud connection instead.
Check storage networking too. If firewall support is on for your Databricks workspace storage account, the Azure Databricks connector documentation requires a VNet or on-premises gateway for CloudFetch. The alternative is disabling CloudFetch with EnableQueryResultDownload=0.
Power BI Databricks service principal and OAuth M2M auth
The connector supports Databricks Client Credentials (OAuth M2M), personal access tokens and Microsoft Entra ID. On Azure, a Microsoft Entra service principal works for cloud and gateway connections.
The identity doesn’t change, but the driver path does. After you switch, run one scheduled refresh under the service principal. Then confirm its Unity Catalog grants on every catalog, schema and view the model reads.
Governance during the overlap window
For several months your tenant runs both drivers. One workspace refreshes on ADBC, another stays pinned to ODBC, and a gateway keeps a third on ODBC. Nobody has a single view of which model takes which path.
Keep the advisor output as your register of which model runs on which driver, and re-run it after every change. Grant reviews apply to both paths, so finish them before the default flips, not after.
Should you use DirectQuery or Import on Databricks?
ADBC makes the pipe faster. It doesn’t change how DirectQuery works. Every slicer click still sends SQL to your SQL warehouse and waits on the round trip.
That costs warehouse time on every interaction. For most large models, I recommend Import mode with incremental refresh instead. Users get in-memory speed, and the warehouse works on a schedule you control.
Power BI incremental refresh on Databricks needs two things. First, filter a date column with the RangeStart and RangeEnd parameters. Second, confirm that filter folds to the warehouse. Each refresh then reloads only the recent partitions your policy defines.
Power BI Databricks DirectQuery performance optimization starts with using fewer DirectQuery tables. Keep it for the few tables where users need current-state data, and build those on Databricks.Catalogs. Microsoft doesn’t support Databricks.Query with DirectQuery.
The same logic shapes Power BI Copilot query performance. Copilot works on your semantic model, so on a DirectQuery model its questions hit the SQL warehouse just like a slicer click does.
What does a safe ODBC to ADBC migration checklist look like?
Moving from ODBC to ADBC in Power BI is a measurement problem before it is a configuration problem. That is Databricks plus first principles thinking: know your baseline before you change anything.
- Inventory every semantic model. Run Microsoft’s read-only pq-adbc-advisor notebook in Fabric. It covers semantic models, Dataflows Gen2 and data pipelines. Each item gets labeled “will fail,” “needs review” or “ready.”
- Test refresh times side by side. Turn on the ADBC workspace override in a pilot workspace and keep production on ODBC. Refresh through a cloud connection. Compare row counts, column types and refresh duration against your ODBC baseline.
- Switch. Remove
Implementation="1.0"pins, or set"2.0"on critical connections. Re-create the affected queries in Desktop. Then decide on the tenant default. - Monitor. Watch refresh history through the first scheduled cycles. Add the connector’s
QueryTagsoption so Power BI queries show up tagged insystem.query.history, which also separates ADBC traffic from ODBC traffic during the overlap. Re-run the advisor to confirm nothing still pins ODBC.
Where do Unity Catalog metric views fit under Power BI?
Back to that board deck. A faster driver delivers a wrong number faster. My client’s problem was three definitions of one KPI, not the pipe.
As a Lean Six Sigma Master Black Belt, I treat a KPI with three definitions as a defect. The fix is one definition, held in the governed layer of the lakehouse.
Unity Catalog metric views define a measure once, with its dimensions and filters. That definition becomes your lakehouse semantic layer, the reference every consumer gets checked against: Power BI, Databricks SQL and Databricks Genie.
This is the real test of GenBI readiness. Databricks AI/BI and Power BI Copilot answer plain-language questions, and a tool asked about a KPI with three definitions picks one of them. ADBC’s faster transfer only pays off once the definition underneath it is single.
Keep DAX thin. If a measure carries business logic, that logic belongs in the gold layer. Our Azure Databricks architecture guide covers how to lay those layers out.
One warning before you add security. Don’t switch on per-user row-level security until your caching is identity-scoped. Get that order wrong and dashboards slow down, and one user can see another user’s cached result.
What should decide when you migrate?
Four facts set your timeline. How many items the advisor marks “will fail.” Whether you depend on a gateway for private networking. How much of your reporting runs on DirectQuery. And which credential type your scheduled refreshes use.
If the advisor shows zero “will fail” items and you run no gateways, flip a pilot workspace now. If you rely on a gateway, plan the upgrade path today. The gateway only delays the change.
The deadline isn’t the real risk. The silent flip of unpinned connections is. Test before the default changes for you.
Your next step is to run the advisor this week and sort every model into “will fail,” “needs review” and “ready.” If you want a second set of eyes on that audit, your gateway plan or your semantic model design, talk to the Analytics AIML data engineering consulting team. Secure. Solve. Scale.
Frequently Asked Questions (FAQs)
How do I switch an existing Power BI report to ADBC?
In the service, unpinned connections follow the workspace or tenant setting. To force ADBC, open the Advanced Editor and add Implementation="2.0" to the Databricks.Catalogs options. In Desktop, delete the query, re-add the source and re-select the fields.
Will my reports break when ODBC leaves the Power BI service?
Models that pin Implementation="1.0" with no gateway binding will fail at cutover. Unpinned models move to ADBC automatically. Gateway-bound models keep running on ODBC for now.
Does ADBC support service principal authentication on Databricks?
Yes. The connector lists Databricks Client Credentials (OAuth M2M) and, on Azure, Microsoft Entra service principals for cloud and gateway connections. After switching, run a scheduled refresh under the service principal and confirm its Unity Catalog grants.
Why are my DirectQuery reports slow on Databricks?
Every visual interaction runs SQL against your SQL warehouse, so you wait on a round trip each time. ADBC speeds up data transfer, but the round trips remain. For large models, Import mode with incremental refresh is the better fix.
Can I stay on ODBC after early 2027?
Only by routing refreshes through an on-premises data gateway with ODBC drivers installed. That is a temporary fix. Microsoft plans to stop shipping the ODBC drivers with the gateway in spring 2027.

