Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks work through the specific warning signs that a Power BI data model is not built to support the reporting it is supposed to deliver. The conversation is diagnostic in nature, giving developers a concrete set of indicators to look for when a model is underperforming or proving difficult to extend, and connecting each symptom back to the underlying architectural decision that caused it.
For any team inheriting a model that feels harder to work with than it should be, or building one and wanting to avoid the most common structural mistakes, this episode provides a practical reference. See how Blue Margin’s Managed Analytics & Insights applies dimensional modeling best practices and rigorous quality standards to every data model it builds, ensuring that Power BI environments perform well, extend cleanly, and can be understood by any developer who picks up the work.
What This Episode Covers
Summarized Data (1:34 – 2:32)
When a report cannot drill down to the level of individual transactions, the data was almost certainly summarized before it reached the model. That decision trades flexibility for convenience in a way that compounds over time: every new report that requires granular detail requires either a model rebuild or a workaround. Preserving transactional-level data in the model is what makes it possible to answer questions that were not anticipated when the model was first built.
Poor Report Performance (2:46 – 4:49)
Slow load times and sluggish cross-filtering are symptoms of a model that is not dimensional. When the model is not built around a star schema, DAX calculations require traversing more table relationships to arrive at a result, which increases compute time and degrades the interactive experience. The star schema recommendation is not purely aesthetic. It is a performance architecture decision with measurable consequences for how the report feels to use.
Complex and Inefficient Schemas (4:51 – 6:28)
Denormalizing data, collapsing multiple tables into one, can improve DAX performance in some scenarios but introduces the risk of model sizes that become unwieldy as data volumes grow. The hosts recommend maintaining separate dimension tables for large datasets, balancing the performance benefits of denormalization against the storage and maintainability costs it creates.
Lack of Readability and Standards (6:36 – 8:28)
A model that only the original developer can navigate efficiently is a liability. The hosts make the case for a set of practical standards that make models more transferable: consistent naming conventions with an ID suffix on foreign keys, avoidance of snowflake schemas that add unnecessary relationship complexity, hiding tables and columns that do not need to be visible to report authors, and formatting rules like no spaces in column names alongside spaces in measure names for readability. These conventions are small individually and meaningful in aggregate.
Who It’s For
This episode is worth your time if you are a Power BI developer who has inherited a model that is slow, difficult to extend, or hard to understand without the original developer available to explain it, a BI team lead trying to establish model design standards before problems accumulate across a report library, a data modeler evaluating whether the architecture choices made early in a project are going to hold up as reporting requirements grow, or any organization that has received complaints about report performance or flexibility and wants to understand whether the model is the source of the problem.
Why It’s Worth a Listen
Data model problems are easy to defer because they rarely announce themselves as model problems. They show up as slow reports, as requests that take longer than expected to fulfill, and as new developers who struggle to get up to speed on existing work. This episode connects those symptoms to their causes in a way that makes the diagnosis more straightforward and the path to a fix more actionable.
The readability and standards section is worth particular attention for teams that support multiple developers working across a shared model library. The conventions the hosts describe are not arbitrary preferences. They are the difference between a model that a new team member can work in productively on day one and one that requires weeks of reverse-engineering before it can be safely modified.
And the framing at the end holds up as a general principle: if a report is performing poorly or is too difficult for another developer to understand, the model is almost always where the problem lives. Treating model quality as a first-class concern rather than something to be addressed after the reporting layer is built is the cleaner and ultimately faster path to a BI environment that scales.
