0

Hi Mendix CommunityI'm trying to connect a Mendix Cloud app to an Azure Databricks SQL warehouse where the workspace is locked down behind Azure Private Link (front-end/inbound, databricks_ui_api sub-resource, public network access disabled).My understanding of the architecture:Mendix Cloud Private Connectivity only supports outbound connections via Tailscale, from the app toward infrastructure I control.Azure Databricks Private Link only accepts connections originating from within the VNet (or a peered/connected network) — it has no way to accept a connection from an external SaaS platform directly.My plan is to deploy a Tailscale subnet router as a VM inside the same Azure VNet that hosts the Databricks private endpoint, advertise the route to that subnet, approve it on the Mendix side, and then connect via the External Database Connector (JDBC) using the workspace's private-endpoint-resolved hostname.Before I build this, I'd appreciate input on a few things:Has anyone actually implemented this pattern (Mendix Private Connectivity → Tailscale relay → Azure VNet → Databricks private endpoint) and can confirm it works end to end, particularly for JDBC/SQL warehouse traffic (not just REST API calls)?Are there known limitations with the External Database Connector's JDBC driver resolving privatelink.azuredatabricks.net DNS records correctly when accessed through a Tailscale-routed path rather than a native VNet client?Is there a supported/recommended alternative to a self-managed Tailscale relay VM for this specific scenario (e.g. does Mendix's Private Connectivity roadmap include any native Azure Private Link peering option)?Setup details: Mendix Cloud (public), Azure Databricks Premium plan, workspace deployed via VNet injection, front-end Private Link enabled, targeting the SQL warehouse via JDBC with a personal access token.Any pointers, war stories, or "don't bother, do X instead" advice welcome.

asked 2026-07-01

1 answers