Forum Discussion
Advocate IILakehouse vs Warehouse
For DP-600 prep, I'm a bit confused on when you'd choose a Lakehouse over a Data Warehouse in Fabric for the same project. Are there real-world scenarios where one is clearly better than the other?"
There are real-world scenarios where one is clearly a better fit.
I’d keep it simple:
Use a Lakehouse when the data is still raw, messy, changing, or coming from different formats. For example CSV, JSON, logs, APIs, files, or data that needs Spark/notebook processing. It fits well for ingestion, cleaning, bronze/silver layers, data engineering, and data science.
Use a Warehouse when the data is already clean, structured, and ready for analytics. For example curated sales, finance, customer, or operational reporting tables. It fits well for T-SQL, star schemas, dimensional models, and Power BI reporting. You have created good data products in your own on-premise data warehouse and you import into Fabric Warehouse and so some last mile transformations.
A common real-world pattern is to use both:
Lakehouse = land and prepare the data
Warehouse = serve clean, structured data for BIExample:
API data, raw files → Lakehouse
Curated finance/sales reporting model → WarehouseMicrosoft’s decision guide says something similar: choose Lakehouse for Spark, mixed or unknown data types, and flexible data engineering; choose Warehouse for T-SQL, structured data, and multi-table transactional warehouse needs. https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-lakehouse-warehouse
Best regards,
Parchitect - Solutions Architect
💡Did my response help you? Clicking Kudos is a small gesture that goes a long way!
✔️Did I answer your question? Please mark my post as a Solution to help others find it faster.
3 Replies
Dear Parchitect,
I have a follow-up question about our specific architecture.
We have an existing star schema in our on-premises SQL Server data warehouse, and we want Fabric to become the starting point for our analytical community. We're using copy jobs to replicate that star schema into Fabric.
Our vision is for individual departments to build their own analytical pipelines in separate workspaces, each potentially with its own Lakehouse. These pipelines will perform further joins, merges, and data enrichment using the replicated star schema as their starting point.
The star schema itself will remain unchanged in Fabric. Any transformations required during ingestion will be handled through SQL commands embedded in the copy jobs. In other words, we're looking to replicate our existing, curated star schema as a shared source for downstream analytical work.
Given this architecture, would you recommend storing the replicated star schema in a Fabric Warehouse or a Lakehouse?
I'm particularly interested in whether a Warehouse is the more natural choice for this central, relational star schema, while departmental teams use their own Lakehouses for further transformations and enrichment. Or are there advantages to storing the central star schema in a Lakehouse instead, given that it will primarily serve as a source for downstream pipelines?Thank you!
v-veshwara-msftCommunity Support
Hi Sanyukti_Jain ,
Thanks for reaching out to Microsoft Fabric Community.Just wanted to check if the response provided by Parchitect was helpful. If further assistance is needed, please reach out.
Thank you.- Parchitect
Solution Sage
There are real-world scenarios where one is clearly a better fit.
I’d keep it simple:
Use a Lakehouse when the data is still raw, messy, changing, or coming from different formats. For example CSV, JSON, logs, APIs, files, or data that needs Spark/notebook processing. It fits well for ingestion, cleaning, bronze/silver layers, data engineering, and data science.
Use a Warehouse when the data is already clean, structured, and ready for analytics. For example curated sales, finance, customer, or operational reporting tables. It fits well for T-SQL, star schemas, dimensional models, and Power BI reporting. You have created good data products in your own on-premise data warehouse and you import into Fabric Warehouse and so some last mile transformations.
A common real-world pattern is to use both:
Lakehouse = land and prepare the data
Warehouse = serve clean, structured data for BIExample:
API data, raw files → Lakehouse
Curated finance/sales reporting model → WarehouseMicrosoft’s decision guide says something similar: choose Lakehouse for Spark, mixed or unknown data types, and flexible data engineering; choose Warehouse for T-SQL, structured data, and multi-table transactional warehouse needs. https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-lakehouse-warehouse
Best regards,
Parchitect - Solutions Architect
💡Did my response help you? Clicking Kudos is a small gesture that goes a long way!
✔️Did I answer your question? Please mark my post as a Solution to help others find it faster.
