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!