Semantic Model Decision

Hi powerbiexpert22​,

The existing answers cover the main factors well. I would add that I normally make this decision around the business boundary of the model rather than around the number of reports or fact tables alone.

A single semantic model can contain multiple fact tables, even at different grains, as long as the model is designed properly around shared dimensions and clear relationships.

Microsoft's star schema guidance is useful here because it focuses on separating fact and dimension tables and keeping fact-table grain well defined.

I would lean toward one semantic model when:

• the reports belong to the same business domain
• they should use the same definitions of KPIs and measures
• they share conformed dimensions such as Date, Customer, Product or Geography
• the security model is compatible
• the data has reasonably compatible refresh/freshness requirements
• the same team owns and governs the model
• users frequently need analysis across the different subject areas in the model

One advantage is reuse. Microsoft supports creating many reports from one published semantic model through a live connection, including reports stored in other workspaces.

That allows you to keep one governed definition of measures such as Revenue, Margin or Active Customer rather than recreating those calculations independently in several models.

I would lean toward multiple semantic models when:

• the business domains are genuinely independent
• the same KPI has different legitimate definitions for different domains
• security boundaries are substantially different
• different teams own and release the models independently
• refresh frequencies or latency requirements are very different
• the storage modes or source architectures are different enough that combining them adds unnecessary complexity
• the model becomes too large or difficult to operate within the capacity limits

Microsoft's capacity documentation is also relevant because model memory, refresh parallelism and DirectQuery concurrency limits vary by Fabric SKU.

I would not split a model simply because there are many reports, and I would not combine everything simply because the source tables happen to be related.

Would the business expect these reports to use the same trusted definition of the same entities and measures?

If yes, that is a strong reason to consider one shared semantic model.

If the answer is no because the domains, ownership, security or operational requirements are materially different, separate models are usually cleaner.

There is also a middle option. Power BI supports composite models, so a team can reuse a governed semantic model and extend it with additional data where necessary. I would use that selectively because cross-source relationships, performance and security can become more complex.

My rule of thumb is therefore:

• one coherent business domain with shared definitions -> shared semantic model
• different business/security/ownership boundaries -> separate semantic models
• small extensions to a governed model -> consider a composite model

I would design the semantic-model boundary around business meaning and ownership first, then validate the decision against refresh, security, performance and capacity constraints.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.