Forum Discussion
Lakehouse Data Modeling Tips in Fabric
Hello Fabric Community,
I’m currently preparing for the DP-600 exam and working through Microsoft Learn modules. I’ve started creating a Lakehouse workspace in Microsoft Fabric and want to make sure my data models are optimized.
Could anyone share best practices for structuring tables, relationships, and measures in a Lakehouse for analytics efficiency? Any tips or common pitfalls to avoid would be greatly appreciated.
Thank you in advance for your guidance!
— Schenado
1) Separate Layers
Use a layered approach inside the Lakehouse:
-
Bronze → Raw ingestion (no business logic)
-
Silver → Cleaned & transformed tables
-
Gold → Analytics-ready tables (star schema)
For reporting efficiency, Power BI should ideally connect to the Gold layer.
2) Always Model as a Star Schema
Even in Lakehouse.
Use:
-
Fact tables (transactions, events, metrics)
-
Dimension tables (Date, Customer, Product, Region, etc.)
Avoid:
-
Snowflake schema unless necessary
-
Fact-to-fact relationships
-
Many-to-many unless unavoidable
- Bi-directional unless justified
3) Use Surrogate Keys (Not Natural Keys)
In your Gold layer:
-
Create integer surrogate keys for dimensions
-
Avoid joining on text columns
-
Avoid GUID joins if possible
This reduces storage size and improves relationship performance.
4) Watch Cardinality
High-cardinality columns:
-
Transaction IDs
-
Timestamps at second-level
-
Free-text descriptions
Keep them out of dimensions and visuals if not needed.
-
3 Replies
- cengizhanarslan
Super User
1) Separate Layers
Use a layered approach inside the Lakehouse:
-
Bronze → Raw ingestion (no business logic)
-
Silver → Cleaned & transformed tables
-
Gold → Analytics-ready tables (star schema)
For reporting efficiency, Power BI should ideally connect to the Gold layer.
2) Always Model as a Star Schema
Even in Lakehouse.
Use:
-
Fact tables (transactions, events, metrics)
-
Dimension tables (Date, Customer, Product, Region, etc.)
Avoid:
-
Snowflake schema unless necessary
-
Fact-to-fact relationships
-
Many-to-many unless unavoidable
- Bi-directional unless justified
3) Use Surrogate Keys (Not Natural Keys)
In your Gold layer:
-
Create integer surrogate keys for dimensions
-
Avoid joining on text columns
-
Avoid GUID joins if possible
This reduces storage size and improves relationship performance.
4) Watch Cardinality
High-cardinality columns:
-
Transaction IDs
-
Timestamps at second-level
-
Free-text descriptions
Keep them out of dimensions and visuals if not needed.
-
- v-karpurapud
Community Support
Hi Awesomedev
Thank you for submitting your question to the Microsoft Fabric Community Forum, and thanks to cengizhanarslan for helpful suggestions.
Could you let us know if the suggested solution resolved your issue? If not, please share any additional details so we can assist further.
Best regards,
Community Support Team.- v-aatheeque
Community Support
Hi Awesomedev
Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.