The host name for a SQL Analytics endpoint is ugly.
They look like this:
random_ugly_alphanumeric-random_ugly_alphanumeric.datawarehouse.fabric.microsoft.com
The first segment looks like it is tenant-specific - if I have several workspaces that each have a lakehouse with a SQL analytics endpoint, the first segment is the same for each of them. The secong segment is specific to the workspace - if you have multiple lakehouses in the same workspace, each of the SQL Analytics endpoints have the same hostname. So it appears that there's only one SQL Analytics endpoint in the workspace and it has multple database contexts. I get it.
If I have a bunch of users who have some legacy need to connect via a TSQL endpoint, I need to give them this ugly name. If I have multiple workspaces with similar names, for dev, test, and prod, it is very easy to make a mistake and copy the wrong host name because they have nothing in the host name that links them back to the workspace they are in (except the ugly random alphanumeric string).
Also, I might want to switch users to a different SQL Analytics host name a some point and it means that existing connections need to have their host names updated - ODC files, DSNs, connection strings, etc. It can be a lot of changes to coordinate.
I thought maybe I could use a DNS CNAME record to alias the hostname - testfabricsql.mydomain.com goes to the test workspace's SQL Analytics host name, prodfabricsql.mydomain.com goes to the Prod workspace's, etc. This would make it easy to update the host name in one place. It didn't work, unfortunately - something about the dynamic nature of the network on the Microsoft side.
So, I'd like it if we could have one of these options:
1. support the CNAME option
2. create a named alias in the Fabric workspace
3. have something more recognizable in the host name that is generated. Even if it still has a bunch of random alphanumeric strings in it. (this is difficult because if it is derived from the workspace name, then if you change the workspace name, does it also change the host name? that's probably not great either.)
1 Comment
We have encountered exactly the same issue. We use separate Microsoft Fabric workspaces for our acceptance and production environments, but the generated SQL endpoint hostnames provide no recognizable indication of which environment they belong to.
Supporting CNAME records would allow us to use clear names such as lakehouse-acc.company.com and lakehouse-prod.company.com. This is not merely cosmetic: it would reduce the risk of users, applications, and configuration files accidentally connecting to the wrong environment. It would also provide a stable abstraction if a Fabric workspace or endpoint ever needs to be replaced.
We verified that the CNAME resolves correctly and reaches the Fabric endpoint. The original Fabric hostname connects successfully, but the CNAME connection is reset with error 10054, even when HostNameInCertificate contains the original Fabric FQDN. This suggests the custom hostname is rejected by the Fabric TDS/SNI routing layer.
Support for verified custom hostnames or CNAME bindings would significantly improve environment management, operational safety, and maintainability for organizations using separate development, acceptance, and production workspaces.
