- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2026 08:39 AM
This scenario is supported, but there are a couple of documented limitations.
1. Supported pattern: VNet (or on-prem) gateway → Databricks SQL Warehouse over Private Link (recommended)
- The official Databricks/Fabric guidance explicitly supports connecting the Power BI service to an Azure Databricks SQL warehouse and marking the connection as usable with on-premises and VNet data gateways.
- For M2M OAuth, the connection type “Azure Databricks” is supported via both On-premises and Virtual network gateways; you must configure Databricks Client Credentials (service principal) in the UI for those gateway connections.
- When your workspace uses Private Link / storage firewall, Microsoft explicitly requires a VNet or on-prem gateway so that Fabric/Power BI can reach the workspace storage account for Cloud Fetch, and treats the VNet data gateway as a valid option in this topology.
- There is no documented restriction that excludes serverless or Pro SQL warehouses from being used behind this pattern; BI tools (including Power BI) are supported against Unity Catalog tables on default/serverless storage over ODBC/JDBC.
2. Known limitation: VNet data gateways are not fully supported in Power BI REST APIs
- Microsoft notes that “Power BI does not fully support VNet data gateways in its REST APIs”, which means automation/REST-based operations for these gateways (including updating connections/credentials) are limited and must be done manually in the UI.
- This limitation is control-plane only (management via REST), not a data-plane connectivity block, but it can manifest as confusing errors referencing
api.powerbi.comduring connection creation or updates, even though the underlying Databricks endpoint is reachable.
3. Alternative if issues persist: fall back to an on-premises gateway for isolation testing
- The same configuration flow (connection type Azure Databricks, Databricks Client Credentials, private access to the workspace/storage) is documented for on-premises gateways as well as VNet gateways.
- If your VNet data gateway continues to time out despite NSG and routing looking clean, standing up a test on-prem gateway in a peered VNet or connected network is a fully supported alternative and a good way to determine whether the issue is specific to the VNet data gateway implementation vs. general connectivity to the Databricks Private Endpoint.
Recommendation
Configure the connection in Power BI Service using Connection type = Azure Databricks with Databricks Client Credentials on your existing VNet data gateway, and manage that connection only via the UI (not REST). If you still see timeouts referencing api.powerbi.com, use an on-prem gateway with the same private connectivity as a next step to confirm whether you’re hitting a VNet gateway–specific limitation rather than a Databricks/serverless limitation.