How do you decide whether to build one Lakehouse for all departments or a separate Lakehouse

[Lili2025]

I’m looking for best practices on implementing a Lakehouse architecture across multiple departments in my company. I'm currently unsure whether it’s better to build a separate Lakehouse for each department or to maintain a single, centralized Lakehouse for all departments. Could anyone share insights or guidance to help me make an informed decision? Thank you in advance

[anh_pnl]

I’m in the same situation and have the same question. I’ve looked into both options but still haven’t found a clear answer. I would be grateful for any advice or real-life experiences from others on what worked (or didn’t work) for you. Thanks!

[v-nmadadi-msft · Accepted solution]

Hi @anh_pnl ,
A centralized Lakehouse offers several advantages. It enables a unified data model, making it easier to build cross-departmental reports and analytics. It also reduces data duplication, as all teams consume the same version of shared datasets such as master data, and supports simplified governance for managing shared data assets. However, this approach also comes with challenges. As more departments contribute data, the overall complexity can increase, making the model harder to maintain and optimize. Additionally, larger centralized Lakehouses may experience performance trade-offs, particularly during data refreshes or transformations.

Departmental Lakehouses offer the advantage of decoupled development, allowing each team to manage their own data pipelines, schema, and transformations independently, without impacting other departments. This setup also enables better performance management, as smaller and more focused Lakehouses can be optimized individually.  However, this model has its drawbacks. It can lead to data duplication, particularly for shared entities like master data. Cross-department reporting becomes more complex, often requiring the integration of multiple data sources or maintaining shortcut and query connections. Moreover, this approach introduces more setup and orchestration overhead, as each department's environment must be managed separately.

Thank you

[v-nmadadi-msft]

Hi @Lili2025 ,

Lot of the Architecture depends on your particular requirements and access to whom you want to grant.

You can create a separate workspace for each department and grant access only to the members of that department. This ensures that users can access only their department’s data, preventing unauthorized access to information from other departments.

In the Departmental workspace, you can create as many lakehouses as required based on your needs or for your particular need if you feel one lakehouse will do the work then you can go ahead with just one.

There is no huge benifit of having a single, centralized lakehouse for all the departments.


If this post helps, then please consider Accepting as solution to help the other members find it more quickly and consider giving a KUDOS. Feel free to reach out if you need further assistance.
Thank you

[Lili2025]

Thank you for your reply. However, are there any clear pros and cons between the two approaches? I have a large amount of departmental data, such as purchase data, sales data, finance data, and also common master data shared across all departments.
Would it be advisable to separate the master data into its own dedicated Data Lake, or should it be integrated into a single, unified Lakehouse?

[v-nmadadi-msft]

Hi @Lili2025 ,

Since you have large departmental data common master data, a hybrid model would likely serve you best. In this approach, you can create separate Lakehouses for each department within the same workspace, ensuring clear data ownership and access control. At the same time, store shared master data in a dedicated Master Data Lakehouse. This master data can then be reused across departments by leveraging shortcuts or queries, allowing each department to access the necessary reference data without duplicating it. This setup promotes modularity, scalability, and secure data sharing across the organization.

To learn more about shrotcuts check these articles:
Unify data sources with OneLake shortcuts - Microsoft Fabric | Microsoft Learn
Create and manage a OneLake shortcut - Microsoft Fabric | Microsoft Learn

If this post helps, then please consider Accepting as solution to help the other members find it more quickly and consider giving a KUDOS. Feel free to reach out if you need further assistance.
Thank you

[anh_pnl]

Thank you for your answer! Besides the benefits of easier access management and security, could you share any other pros and cons of each approach?
If we don’t consider security and access control, which option would you recommend and why?