Pastaba.
Prieigai prie šio puslapio reikalingas įgaliojimas. Galite bandyti prisijungti arba pakeisti katalogus.
Prieigai prie šio puslapio reikalingas įgaliojimas. Galite bandyti pakeisti katalogus.
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
Implementationparameter 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
- 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.
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.
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.