Forum Discussion
Choosing connection types for lakehouse
Hi lskumardadi,
This is a great question, and I think it highlights one of the current design considerations in Fabric.
Today, Lakehouse connections are scoped to a specific Lakehouse, so if each project owns its own Lakehouse, it's expected that the number of SQL Analytics Endpoint connections will grow. At the moment, there isn't a concept of a single generic SQL connection that can dynamically target multiple Lakehouses.
From an enterprise perspective, I've generally seen customers follow these practices:
Use service principals or managed identities (where supported) instead of personal OAuth accounts for production workloads.
Treat connections as environment infrastructure (DEV/QA/PROD) and provision them through CI/CD or Infrastructure-as-Code, rather than creating and maintaining them manually.
Maintain one connection per Lakehouse only when the Lakehouse represents a separate security or ownership boundary. Although this increases the connection count, it provides clear governance, auditing, and least-privilege access.While having 15, 50, or even 100+ connections may initially seem excessive, the operational overhead becomes much smaller once connection creation and deployment are automated.
If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let me know. Thanks a lot!
Memorable MemberHi lskumardadi,
I think the key point here is that the connection should normally be designed around the shared security and access boundary, not automatically around each individual project.
If all five projects need the same type of access to the same Lakehouse, I would avoid creating five separate connections unless there is a genuine need for separate credentials, ownership or isolation.
A practical approach would be:
- Use a shared organisational or service identity rather than individual user OAuth for production workloads.
- Reuse the same connection where the projects have the same permissions and lifecycle.
- Create separate connections only where projects require different identities, different access levels, separate ownership or stronger isolation.
- Apply a consistent naming convention so connections remain easy to identify as the environment grows.
For example, instead of creating one connection per project, you could define connections by environment and access pattern, such as:
- DEV - Lakehouse - ReadWrite
- TEST - Lakehouse - ReadWrite
- PROD - Lakehouse - ReadOnly
If a particular project requires elevated access or a different identity, then that project can have its own dedicated connection.
I would also avoid relying on a personal OAuth connection for long-running production workloads, because it creates a dependency on an individual account and can become harder to manage when ownership changes.
So in your case, I would not assume that five Lakehouses must always mean five completely separate connection strategies. I would first group them by:
- Environment
- Required permissions
- Authentication identity
- Ownership and support responsibility
Then create only the minimum number of connections needed to represent those boundaries.
The main question is therefore not really “how many projects do I have?”, but “how many distinct security and operational boundaries do I need to manage?”
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.