Transition from ODBC to ADBC drivers in Power BI and Fabric

Power BI and Microsoft Fabric are transitioning supported data source connections from legacy embedded ODBC drivers to Apache Arrow Database Connectivity (ADBC) drivers. ADBC provides a set of standard interfaces for interacting with Arrow data, which is especially efficient at fetching large datasets with minimal overhead and no serialization or copying. The ADBC drivers also incorporate security enhancements, such as memory safety and garbage collection.

Note

The tenant and workspace controls described in this article are being enabled in phases and might not yet be available in all tenants. This transition applies only to the connectors listed in this article and doesn't change behavior for the ODBC connector when you use a separately installed ODBC driver. The change in this article is the transition away from embedded drivers that ship with Power BI.

You can adopt ADBC today per-connection, and administrators can control the default behavior at scale using a tenant setting that workspace admins can override for testing and validation.

Connectors and driver changes

The following table lists the connectors that are transitioning from embedded ODBC drivers to replacement drivers. In most cases, the replacement driver is an ADBC driver.

Connector	Current driver	Replacement driver
Databricks	Simba Spark ODBC	Databricks ADBC
Azure Databricks	Simba Spark ODBC	Databricks ADBC
Dremio	Simba Drill ODBC	FlightSQL ADBC
Google BigQuery and Google BigQuery (Microsoft Entra ID)	Simba Google BigQuery ODBC	BigQuery ADBC
Hive	Simba Hive ODBC	Deprecated
Impala	Simba Impala ODBC	HiveServer2 ADBC
Snowflake	Simba Snowflake ODBC	Snowflake ADBC
Spark	Simba Spark ODBC	HiveServer2 ADBC

Who is affected

You're affected if you use any of the connectors transitioning to ADBC (such as Databricks, Snowflake, or Google BigQuery) and:

You haven't explicitly chosen an implementation in the connection (the Implementation parameter isn't specified), or
Your organization wants centralized control over whether ADBC or ODBC is the default for supported connectors.

This default applies wherever you create a connection, including semantic models, Dataflows Gen2, and paginated reports.

How to migrate

You can migrate in three ways, ordered by how much control you want:

Per-connection opt-in: Add Implementation="2.0" to individual connections to validate ADBC at your own pace.
Tenant setting: Set the organization-wide default through the Admin portal.
Workspace override: Override the tenant default at the workspace level for side-by-side validation.

Per-connection opt-in

You can opt in to ADBC by adding Implementation="2.0" to supported connections. This approach lets you validate ADBC at your own pace for individual connections.

For detailed instructions on opting in per-connection for a specific connector, see the connector-specific documentation linked in the Connectors and driver changes table.

Tenant setting

Tenant admins can set the organization's default using the Admin portal setting:

Users can connect to data sources by using Apache Arrow database connectivity (ADBC)

Disabled (default): Selects the legacy ODBC drivers as the default option.
Enabled: Selects the new ADBC drivers as the default option.

This setting also controls the Test Connection behavior for each connection type inside the tenant.

Workspace override

The tenant setting delegates to workspaces, so workspace admins can override the default and compare behaviors without modifying each individual connection. This approach allows side-by-side validation. For example, you can use one workspace to test ADBC defaults while keeping another workspace on ODBC defaults.

How the implementation is chosen

If you explicitly specify the Implementation parameter in the connection, that value always takes precedence over the tenant or workspace defaults.

The following table shows how the driver is selected:

Condition	Driver used
`Implementation="2.0"`	ADBC
`Implementation` not specified and workspace setting is On	ADBC
`Implementation="1.0"`	ODBC
`Implementation` not specified and workspace setting is Off	ODBC

On-premises data gateway behavior

The tenant and workspace ADBC settings apply to refresh paths that run in the cloud service. Queries that route through an on-premises data gateway continue to use the driver bundled with the gateway installation, which today is ODBC for the connectors listed in this article. Gateway-routed refreshes don't switch to ADBC when the tenant or workspace setting is enabled, and this is expected behavior.

Two consequences to be aware of when planning your migration:

If you're using a gateway to test the transition to ADBC, refreshes through the gateway won't reflect the ADBC path. Test ADBC using a cloud connection to accurately validate ADBC behavior end-to-end.
Customers who need to remain on ODBC (for example, to preserve a private-link path through the gateway) can defer the change by continuing to route refreshes through the on-premises gateway with the ODBC drivers installed. This is a deferral, not a permanent opt-out: once ODBC drivers are removed from future gateway installations (see Key dates), gateways pinned to earlier releases eventually become unsupported. Plan gateway upgrades and ADBC validation accordingly.

Recommended migration checklist

Audit your workspace with pq-adbc-advisor to inventory every connection that pins the legacy driver and see a per-item risk classification. See Audit your workspace with pq-adbc-advisor.
Pick a pilot workspace and enable ADBC there first using the workspace override to validate key datasets and refresh scenarios. To validate the ADBC path end-to-end, test using a cloud connection — see On-premises data gateway behavior for why gateway-routed refreshes stay on ODBC.
Validate in Power BI Desktop. Install the current Power BI Desktop release, which ships the ADBC driver for every in-scope connector that has passed its default flip. There's no per-file toggle to force ADBC on an existing query — to route an existing query to ADBC, delete the query, re-add the source, and re-select the fields. Refresh and compare row counts, column types, and refresh duration against your ODBC baseline.
For any critical connections you want to validate immediately, opt in per-connection with Implementation="2.0".
Once validation is complete, decide whether to enable ADBC by default at the tenant level.

Audit your workspace with pq-adbc-advisor

Before you migrate, you need to know what to change. pq-adbc-advisor is a read-only Fabric notebook that scans a workspace and returns a per-item impact report showing which semantic models, dataflows, and data pipelines still pin the legacy ODBC driver and what to do about each one.

Note

This diagnostic is a starting-point diagnostic, not a final audit. Treat the impact report as the first pass to find the bulk of the work. Connector coverage is expanding, and there are corner cases that standard connectors don't yet map cleanly. The tool flags those cases explicitly and points you to a mailbox where the team routes them. For high-value production reports, validate the ADBC path in a copy of the item before you flip production over.

What the impact report gives you

The impact report gives you:

An inventory of every migrating connector call in the workspace across the connectors transitioning to ADBC.

A cutover risk classification for each item:

Risk	What the risk means	What to do
Will fail	The M query pins `Implementation="1.0"` and the item has no gateway binding. At cutover, this refresh stops working.	Remove `[Implementation="1.0"]` from the source step, or bind the item to a gateway before cutover.
Needs review	Either the M query pins ODBC but a gateway is bound (survives cutover but should still be flipped), or the M builds a raw DSN string that ADBC doesn't consume verbatim.	Test the ADBC path in a copy of the item, then roll out. For DSN-string cases the standard connector doesn't cover, escalate to the escalation mailbox listed in the accelerator.
Ready	The M query already pins ADBC (`Implementation="2.0"`), or is unpinned and the tenant switch handles it cleanly.	No action. Re-scan after cutover to confirm.

Coverage for Data Pipelines and Dataflow Gen2, not just semantic models.
Resolution tracking across scans - every scan carries both a first-run baseline and a current-run counter, so a re-scan tells you what's been cleaned up since the first pass.

What the impact report doesn't do

The impact report doesn't:

Rewrite any M expressions.
Trigger refreshes on its own (a separate opt-in entry point is provided for validation).
Send M code, item names, endpoint URLs, credentials, or refresh error message bodies outside the workspace.

Every scan sends anonymous counts to the Power Query team so they can measure adoption and prioritize connector coverage. The scan sends only SHA-256-hashed tenant and user identifiers, with no raw values by default. To opt out at any time, disable telemetry as documented in the accelerator. The opt-out persists across kernel restarts.

How to run the impact report

The easiest way to use the tool is through the starter notebook in the Microsoft Fabric Toolbox.

Download the starter notebook and import it into a Fabric workspace.
Attach the notebook to the workspace you want to inventory.
Run the notebook top to bottom. It installs pq-adbc-advisor into the session, scans the workspace, renders the impact report inline, and saves an HTML copy of the report to the default lakehouse if you attach one.
Make your fixes.
Re-run the notebook. The report shows the resolution deltas - how many pins you cleaned up since your first scan.

If you have admin permissions and want to sweep every workspace in the tenant, the accelerator documents a tenant-wide scan option that uses the Fabric admin Scanner API. Tenant scans typically take 15–30 minutes for a mid-sized tenant.

For bugs, feature requests, and connector coverage gaps, see the accelerator repository.

Key dates

July 2026 (planned): Broad rollout of the tenant setting begins. Workspace behavior inherits this setting and can be overridden by workspace admins where supported.
August 2026 (planned): Microsoft plans to begin enabling the tenant setting by default in phases, subject to rollout readiness.
Late Q3 to early Q4 2026 (planned): Microsoft plans to begin removing ODBC drivers from the service, subject to rollout readiness. If you need to stay on ODBC (Implementation="1.0" or workspace setting Off), you must use a gateway to continue running queries with ODBC.
Spring 2027 (planned): The ODBC drivers referenced in this article are planned to no longer ship with Power BI Desktop or the gateway.

Before enforcement milestones, Microsoft plans to provide advance notice so customers can complete migration and validation activities.

Frequently asked questions

Can I test ADBC now?

Yes. Install the current Power BI Desktop and re-add any in-scope source — new queries route to ADBC immediately. For service-side testing, use the workspace override to enable ADBC on a pilot workspace and validate through a cloud connection.

How do I find every place I'm still using the legacy ODBC driver?

Run pq-adbc-advisor against your workspace. It's a read-only Fabric notebook that inventories every semantic model, dataflow, and Data Pipeline that still uses the legacy driver. It classifies each one by cutover risk and shows what to change. Treat it as your starting-point diagnostic, not a final audit. See Audit your workspace with pq-adbc-advisor. Admins can run a tenant-wide sweep via the Fabric admin Scanner API. See the accelerator documentation for details.

Am I affected if I'm already using the on-premises data gateway?

The tenant and workspace ADBC settings only apply to executions in the service — they don't impact refreshes routed through an on-premises data gateway. Gateway-routed refreshes continue to use ODBC through cutover for the connectors in this article. See On-premises data gateway behavior. ODBC drivers are planned to be removed from future gateway installations — track Key dates for timing.

How can I opt out of the ADBC transition?

You can't permanently opt out. The tenant setting lets you defer the default flip during the validation window, but once ODBC is disabled in the service, the change is universal. To continue using ODBC after the service-side cutover, you must route refreshes through an on-premises data gateway with ODBC drivers installed. This change is a deferral only — ODBC drivers are planned to be removed from future gateway installations.

Why doesn't the workspace ADBC setting change my Power BI Desktop file?

There is no per-file toggle for ADBC in Power BI Desktop. Existing queries in a Desktop file remain on whichever driver they were authored against until the query is re-created. To validate ADBC for an existing query, delete the query, re-add the source, and re-select the fields. New queries in the current Desktop release route to ADBC automatically for connectors that have passed their default flip.

Does the workspace ADBC setting rewrite my existing M queries?

No. The tenant and workspace settings change which driver is selected at query execution time, but they don't modify the M expression itself — hostnames, ports, connection parameters, and connector arguments in your M stay exactly as authored. This behavior applies to both newly created and existing connections: any connection that doesn't explicitly pin Implementation in the M follows the workspace/tenant default the moment it flips.

Connections that pin the driver in M take precedence over the workspace/tenant default. A connection with Implementation="1.0" stays on ODBC, and Implementation="2.0" stays on ADBC, regardless of the workspace or tenant setting. To change one of these, edit the M.

For connector-specific behavior (including any port or option differences between the ODBC and ADBC drivers), see the connector-specific documentation linked in the Connectors and driver changes table.

Feedback

Was this page helpful?

Last updated on 2026-09-03