cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

VNet Data Gateway unable to connect to Azure Databricks Serverless SQL via Private Endpoint

LokeshChikuru
Databricks Partner

I’m facing connectivity issues when trying to connect Microsoft Fabric / Power BI to Azure Databricks Serverless and PRO SQL Warehouse using a VNet Data Gateway. I’m looking for guidance on whether this scenario is supported or if there are known limitations.

Current setup

  • Azure Databricks workspace and VNet Data Gateway subnet are in the same VNet
  • Databricks is accessed via Private Endpoint
  • Gateway subnet:
    • Has outbound access to api.powerbi.com on TCP 443
    • Has outbound access to Azure Databricks Private Endpoint on TCP 443
  • NSG diagnostics (Gateway → Databricks PE :443) are successful
  • No UDRs, no forced tunneling, system routes only
  • Corporate firewall is not in the traffic path
  • Databricks Serverless SQL Warehouse works fine from Databricks SQL UI

 Issue observed

When testing or creating the connection via VNet Data Gateway, I consistently get errors like:VNet Data Gateway 01: ODBC: ERROR [HY000] [Microsoft][ThriftExtension] (14) Unexpected response from server during a HTTP connection: connect() failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond..Session Id: 2ece67bd-78ed-4f9e-ad67-f7c95fd1379a
RequestId: 6a566442-3d6b-4b5c-8be9-c735022fbab8
Cluster URI: https://api.powerbi.com
Status code: 400
Time: Tue Apr 28 2026 09:10:52 GMT+0000 (Coordinated Universal Time)

  • The error always references api.powerbi.com
  • No queries appear in Databricks SQL Warehouse query history
  • No useful logs are available on Databricks side
  • Gateway diagnostics show ā€œNetwork alias interface: Ethernetā€ (default)
2 REPLIES 2

Lu_Wang_ENB_DBX
Databricks Employee
Databricks Employee

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.com during 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.

LokeshChikuru
Databricks Partner

We are able to fix the connectivity issue by correcting the NSG rules between Azure Databricks private endpoint and Fabrics Vnet gateway subnet.

But errors are being occured while powerBI service semantic model query refresh using same Databricks connection. Query results are being staged in workspace managed storage account and pulled by powerBI service and failing to download these results. Though we have our customer managed storage account. 

{"error":{"code":"DM_GWPipeline_Gateway_MashupDataAccessError","pbi.error":{"code":"DM_GWPipeline_Gateway_MashupDataAccessError","parameters":{},"details":[{"code":"DM_ErrorDetailNameCode_UnderlyingErrorCode","detail":{"type":1,"value":"-2147467259"}},{"code":"DM_ErrorDetailNameCode_UnderlyingErrorMessage",

"detail":{"type":1,"value":"Failed to download file from https://xxxxxxxxxxxxx.blob.core.windows.net/04Z_b29f42ce-232c-42e2-a9af-05ce48522f13 after 15 attempts over 856.9s (timeout: 300s).
Last error: HttpRequestException"}},{"code":"DM_ErrorDetailNameCode_UnderlyingHResult","detail":{"type":1,"value":"-2147467259"}},{"code":"Microsoft.Data.Mashup.ErrorCode","detail":{"type":1,"value":null}},{"code":"Microsoft.Data.Mashup.ValueError.Reason","detail":{"type":1,"value":"DataSource.Error"}}],"exceptionCulprit":1}}}
Cluster URI: