Microsoft Fabric Lakehouse SQL Analytics Endpoints: One Per Workspace, Not Per Lakehouse
Some Background
What’s up, if you don’t work with Microsoft Fabric (Microsoft’s latest greatest data everything platform) this article will make no sense. But if you do, welcome. Let’s get straight to it.
I’m here to clear up some confusion evidenced by posts like these from members of the Microsoft Fabric community:
For a given Microsoft Fabric Workspace, do the Lakehouse databases each have their own SQL Analytics Endpoint, or do they share the same one?
Answer: They share the same one. All Lakehouses in a given Fabric Workspace share the same SQL Analytics Endpoint. But it wasn’t always that way. Here’s what’s up.
Things Changed
According to this Microsoft documentation page:
The number of SQL analytics endpoints in a workspace matches the number of Lakehouse items.
Reading that, you’d naturally think: “Okay, so if I have 3 Lakehouses in my workspace, I’ll have 3 different SQL endpoints to connect to.” Right? At least to me, that’s how the language comes across. And well, that used to be true, but not anymore.
Things Now
The only thing you need to know is: All Lakehouses within a single Fabric workspace share the same SQL Analytics Endpoint. When you copy the SQL Analytics Endpoint of any Lakehouse in your workspace from the Fabric UI, that endpoint is good to connect to all the Lakehouses.
There used to be one endpoint per Lakehouse, but that sucked and customers complained. Now, there is one endpoint per workspace, and each Lakehouse appears as a separate database on that endpoint.
An Example
Let’s say you have a workspace called ImportantDataHub with the following SQL endpoint:
SQL Endpoint: dfsakdsdk9329292.datawarehouse.fabric.microsoft.com
You’ve created three Lakehouses in this workspace with cool names:
When you connect to that single SQL endpoint, you’ll see all three databases:
-- Connect to: dfsakdsdk9329292.datawarehouse.fabric.microsoft.com
-- Available databases:
USE Kumogakure; -- Your first Lakehouse
USE Sunagakure; -- Your second Lakehouse
USE Konohagakure; -- Your third Lakehouse
This is actually closer to traditional SQL Server behavior. You can use USE statements to switch database context. At least, the USE statement works from SSMS 22. I’m less sure about whether it works from the Fabric Workspace UI where I had some issues. Point is, you don’t need a different connection string for every database.
Working With The New Endpoints
Now, since it’s an auto-created endpoint, as Microsoft states here:
There’s no need to create a SQL analytics endpoint in Microsoft Fabric. A SQL analytics endpoint is automatically created for every lakehouse, database, or mirrored database
It’s a pretty ugly URL. A bunch of gibberish. Pretty hard to tell what it’s pointing to if you’re in a situation where you have many Fabric workspaces.
Thankfully, the latest version of SQL Server Management Studio (SSMS) has added features such that when connecting from it to a Fabric SQL Analytics Endpoint, the pretty name of the workspace shows up.
Read the full details of SSMS 22 here: SQL Server Management Studio (SSMS) 22 is Now Generally Available
It ends up looking like this when you connect. You can see the Fabric language now integrated into the platform. The black bar, redacted for privacy, would show the name of the Fabric workspace on which the SQL Analytics Endpoint sits.
And side note, I’m digging the new SSMS logo. Makes me feel very modern, very suave, very cool. Like a cool, hip, in the know, data kind of guy, rather than an ancient on-premises SQL Server legacy infrastructure DBA type of guy, which I’m totally not. But looking at the old SSMS logo did at times make me feel like one of those legends (shout out to everyone doing data engineering before both ChatGPT and StackOverflow, you deserve your flowers).
Why This Is Actually Better
I think this architecture is actually better. It makes my life easier at least. In the early days, each Lakehouse had its own endpoint. At some point recently, Microsoft changed this. The documentation just hasn’t caught up yet.
Here’s why having one endpoint per workspace is superior:
- You only need to manage one connection string per workspace instead of N connection strings for N Lakehouses. Makes your CI/CD pipelines and configuration files simpler.
- If you’re coming from a SQL Server background (which many working with Fabric are), this feels natural. One server, multiple databases. We already know how to work with this model.
Closing Thoughts
Microsoft Fabric is rapidly evolving, and sometimes the documentation takes time to catch up with product changes. They’ll get it updated eventually.
The best place to hangout, ask questions, and get the latest is r/MicrosoftFabric. The Fabric product team engages directly there, and the community keeps it real, both with frustrations and praise when deserved.
Now go forth and connect to your Fabric Lakehouses with confidence. You’ve got one endpoint to rule them all.
