Forum Discussion
Lakehouse Build
Hi Experts , we are developing bronze layer as of now , so as per Microsoft Fabric's best practices , I have suggested the having lh_bronze, lh_silver and warehouse_gold. The client was of the opinion that it would be better to have one lakehouse and segregate it by naming. I want to understand the best way forward. And , the impact in terms of cost , and future development. Thank you in advance.
Hi SamyAbdul,
Your client’s one-lakehouse approach can work technically, especially now that Fabric Lakehouse supports schemas, but I would still prefer separate layers for a production medallion design unless there is a strong reason to combine them.
Microsoft’s medallion architecture guidance for Fabric recommends keeping Bronze, Silver and Gold as separate layers, typically in separate Lakehouses/Warehouses.
A common pattern would be:
Bronze Lakehouse → raw/source-aligned data Silver Lakehouse → cleansed, standardized, deduplicated and conformed data Gold Warehouse or Lakehouse → business-ready facts, dimensions and aggregatesThe main advantage is not really performance - it is operational separation. Separate layers make permissions, ownership, deployment, troubleshooting, reprocessing and lifecycle management much clearer.
For Gold, I would also consider a Warehouse if the main consumers are Power BI and SQL users. Microsoft explicitly documents Bronze/Silver in Lakehouse and Gold in Warehouse as one of the supported medallion deployment patterns.
In terms of cost, having three items does not automatically mean three times the cost. Fabric consumption is driven more by storage, transformation workload, query activity and CU usage than by the number of Lakehouse objects themselves. The same data processed in the same way will generally have a similar storage footprint, although different architectures can change how much compute is consumed during processing.
A single Lakehouse with bronze/silver/gold schemas is still valid, and Microsoft also shows schema-based patterns in current Lakehouse guidance. I would mainly choose that for smaller or simpler solutions where governance and operational separation are less important.
So for a scalable enterprise design, I would stay with your lh_bronze / lh_silver / warehouse_gold approach unless the client has a specific requirement that makes a single Lakehouse materially simpler.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
3 Replies
- VM_DataViz24New Member
Hi SamyAbdul,
I personally think both options are good enough. However, let's think from data engineering perspective why Microsoft is suggesting the best practices approach is more clarity of you medallion architecture.
I am personally following this as for my organization as it will give me more clarity to my lineage as I am about to start my Data Governance journey with Purview.
So I would suggest if you have data governance in mind for future, you should follow the best practices.
Hi SamyAbdul,
There is no real difference in cost, the same amount of data will consume the same capacity in one lakehouse or two lakehouses if the use case is the same.
Operationally, I find it easier to have separate lakehouses. In my bronze lakehouse, I create schemas for each source system and then my bronze table names match the source table name exactly, so there is no confusion where the data comes from.
If you wanted to have a bronze schema and then prefix table names with the source name, that would work but after a few sources will start to get hard to work with.
So what the client is asking for could be done, but what you're suggesting is easier to maintain and work with in my opinion.
- ShivekMaharaj
Community Champion
Hi SamyAbdul,
Your client’s one-lakehouse approach can work technically, especially now that Fabric Lakehouse supports schemas, but I would still prefer separate layers for a production medallion design unless there is a strong reason to combine them.
Microsoft’s medallion architecture guidance for Fabric recommends keeping Bronze, Silver and Gold as separate layers, typically in separate Lakehouses/Warehouses.
A common pattern would be:
Bronze Lakehouse → raw/source-aligned data Silver Lakehouse → cleansed, standardized, deduplicated and conformed data Gold Warehouse or Lakehouse → business-ready facts, dimensions and aggregatesThe main advantage is not really performance - it is operational separation. Separate layers make permissions, ownership, deployment, troubleshooting, reprocessing and lifecycle management much clearer.
For Gold, I would also consider a Warehouse if the main consumers are Power BI and SQL users. Microsoft explicitly documents Bronze/Silver in Lakehouse and Gold in Warehouse as one of the supported medallion deployment patterns.
In terms of cost, having three items does not automatically mean three times the cost. Fabric consumption is driven more by storage, transformation workload, query activity and CU usage than by the number of Lakehouse objects themselves. The same data processed in the same way will generally have a similar storage footprint, although different architectures can change how much compute is consumed during processing.
A single Lakehouse with bronze/silver/gold schemas is still valid, and Microsoft also shows schema-based patterns in current Lakehouse guidance. I would mainly choose that for smaller or simpler solutions where governance and operational separation are less important.
So for a scalable enterprise design, I would stay with your lh_bronze / lh_silver / warehouse_gold approach unless the client has a specific requirement that makes a single Lakehouse materially simpler.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.