Introduction
When Power BI reports are slow, the instinct is to optimize DAX expressions or switch from Import to DirectQuery. In most cases, the actual problem is upstream: a poorly designed semantic model that forces inefficient query patterns regardless of how the DAX is written. Slow reports are almost always a data model problem first and a DAX problem second.
This post covers the semantic model design decisions that have the largest effect on Power BI performance — star schema enforcement, relationship cardinality, measure design, and how Direct Lake mode changes the calculus for organizations on Microsoft Fabric.
Star Schema: Why It Is Non-Negotiable in Enterprise Models
The star schema design pattern — fact tables surrounded by dimension tables, joined on surrogate keys — is the foundation of performant Power BI models. Power BI’s in-memory engine (VertiPaq) is optimized for this pattern: low cardinality dimension columns compress efficiently, fact table joins via integer surrogate keys are fast, and DAX filter propagation follows well-defined paths.
The alternative — flattened tables, snowflake schemas, or directly importing normalized relational schemas — breaks VertiPaq’s compression and forces Power BI to execute joins and aggregations that the storage engine is not designed for. A single flattened fact table with 50 columns, many of which are low-variance categorical fields repeated across millions of rows, will perform dramatically worse than the equivalent star schema with properly separated dimensions.
The practical implication is that Power BI data model design requires deliberate transformation work — either in Power Query, Azure Data Factory, or at the source — to produce a star schema structure. Connecting Power BI directly to a transactional OLTP source without a transformation layer is not a design pattern; it is a source of future performance problems.
Relationship Cardinality and Cross-Filter Direction
Relationships in Power BI carry two configuration choices that significantly affect query behavior: cardinality (one-to-many, many-to-many, one-to-one) and cross-filter direction (single, both).
Many-to-many relationships, introduced in Power BI to handle scenarios like bridge tables and role-playing dimensions, carry a performance cost because they require VertiPaq to materialize intermediate results rather than following clean single-direction filter propagation. Use many-to-many relationships where the data model genuinely requires them — not as a shortcut to avoid transformation work that would produce a cleaner star schema.
Bidirectional cross-filtering allows filters to propagate in both directions across a relationship. This sounds convenient but creates ambiguity in complex models — filters can travel unexpected paths, producing incorrect results in measures that were designed for single-direction filter propagation. The default should be single-direction cross-filtering. Enable bidirectional filters only for specific tables where the business requirement clearly justifies it, and document those decisions.
Measure Design: Avoiding Context Transition Overhead
DAX measures evaluate in filter context — the set of filters active when the measure is called. Every use of CALCULATE() creates a new filter context, and every context transition (using row context functions like SUMX() or EARLIER() inside CALCULATE()) has a computational cost that scales with the number of rows being iterated.
Common performance anti-patterns in enterprise models include measures that iterate large fact tables row by row using SUMX() when a simpler SUM() with appropriate filters would produce the same result; measures that call other measures inside CALCULATE() creating deeply nested context transitions; and measures that reference calculated columns for logic that could be expressed more efficiently as a filter-context-aware calculation.
The key diagnostic tool is Performance Analyzer in Power BI Desktop, which shows the DAX query generated by each visual element and the time spent in storage engine versus formula engine evaluation. Formula engine time (processing DAX expressions in memory) is often harder to reduce than storage engine time (reading compressed column data). Measures that generate high formula engine time are candidates for DAX optimization or model redesign.
Direct Lake Mode: The Fabric Model Design Implications
Direct Lake is a Power BI connectivity mode available when the data source is a Fabric Lakehouse or Warehouse. In Direct Lake mode, Power BI reads Delta Lake Parquet files from OneLake directly at query time, without import or DirectQuery. The result combines the performance of Import mode (VertiPaq-speed reading of column-compressed data) with the freshness of DirectQuery (no refresh cycle required).
Direct Lake mode changes several model design assumptions. The data must already be in Delta Lake format in OneLake — Power Query transformations run within the semantic model are not applied before Direct Lake reads the source. This means the Delta tables in the Lakehouse must be properly structured (star schema, correct grain, appropriate column types) before the Direct Lake semantic model references them. The transformation work moves upstream to the Lakehouse, not the semantic model.
Direct Lake also has fallback behavior: if a query cannot be served directly from OneLake (due to complex DAX, certain relationship patterns, or data volume exceeding framing limits), it falls back to DirectQuery mode. This fallback is transparent to the user but slower. Monitoring for Direct Lake fallback events is part of managing a production Fabric-based Power BI implementation.
Conclusion
Semantic model design is the highest-leverage investment in Power BI performance. A well-designed star schema with clean relationships, efficient DAX measures, and appropriate connectivity mode delivers reports that scale. A poorly designed model produces performance problems that no amount of DAX optimization will fully resolve. In Fabric environments, the design discipline moves upstream into the Lakehouse layer — making data engineering and Power BI model design a more integrated concern than they were in traditional Power BI Premium architectures.
Need Power BI application development with semantic models built for enterprise scale? Prism Analytics delivers production-grade Power BI implementations designed to perform from day one. Let’s talk.