Power BI semantic model design: the decisions that determine performance

Power BI performance conversations often focus on visuals and filters. These matter. But the primary determinant of performance is the semantic model design.

Import vs DirectQuery

Import: loads data into Power BI's in-memory engine at refresh time. Very fast queries. Trade-off: freshness bounded by refresh schedule.

DirectQuery: sends queries to the source at interaction time. Always current. Trade-off: query performance depends on the source system.

For most analytical reporting on business data, Import mode is right. For operational dashboards where freshness within minutes matters and volume makes import impractical, DirectQuery is appropriate.

Star schema: the foundation

A central fact table with surrounding dimension tables produces simpler DAX, more efficient queries, and cleaner relationships. Anti-patterns: normalised schemas brought directly from relational databases (flatten them), many-to-many relationships (resolve at the model layer), calculated columns for logic that could be DAX measures.

DAX measure design

• Use CALCULATE with filter arguments rather than nested FILTER functions where possible
• Avoid row-by-row iteration (SUMX) when scalar aggregation (SUM) is sufficient
• Use variables to cache repeated calculations within a measure

A semantic model designed for query performance will outperform a poorly designed one regardless of how the report page is built. Invest in the model first.