Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks share their perspective on semantic modeling in Power BI, challenging some of the conventional wisdom around how transformations should be handled and how tightly governance should constrain the people building reports. The conversation is practical and opinionated, offering a clear point of view on where Power BI belongs in the data stack and where it does not.
For any team that has experienced slow refresh times, memory constraints, or modeling projects that stalled trying to achieve perfection, this episode offers a more workable framework for approaching the problem. See how Blue Margin’s Managed Analytics & Insights applies this balanced approach to semantic modeling, building the right foundation for core reporting needs while preserving the flexibility that allows BI to evolve as business requirements change.
What This Episode Covers
Power BI Is Not an ETL Tool (0:40 – 2:25)
Relying on Power Query for heavy data transformation work creates performance problems that compound as data volumes and model complexity grow. Slow refresh speeds and memory constraints are the predictable consequences of asking Power BI to do work it was not designed to do efficiently. The hosts recommend handling data shaping and modeling upstream using serverless SQL views, keeping Power BI focused on the semantic and visualization layer where it actually excels.
Governance vs. Flexibility (2:34 – 5:22)
The instinct to lock down semantic model creation in the name of governance can work against the agility that makes BI useful in practice. The hosts push back on overly restrictive approaches, arguing that allowing report writers to build their own models, even in a one-to-one relationship between a report and a model, enables the kind of iteration and responsiveness that rigid governance structures tend to prevent. Business needs evolve, and the modeling layer needs to be able to keep pace with them.
Finding the Right Level of Complexity (5:23 – 8:10)
The pursuit of a single, perfectly comprehensive canonical data model is one of the most reliable ways to stall a BI project. The hosts recommend a more pragmatic approach: build a primary semantic layer that handles the majority of requirements well, and allow extensions and edge cases to be addressed in separate models rather than forcing everything into one structure. That balance keeps projects moving, keeps reports performing, and avoids the trap of letting perfect become the enemy of useful.
Who It’s For
This episode is worth your time if you are a Power BI developer or data modeler dealing with slow refresh times or memory issues and wanting to understand whether the transformation architecture is the root cause, a BI team lead evaluating how much governance to impose on report writers building their own models, a data architect trying to define the right scope for a semantic layer without overbuilding it, or any organization that has watched a modeling project drag on in pursuit of a comprehensive solution that never quite ships.
Why It’s Worth a Listen
The framing of Power BI as not an ETL tool is one of those reorientations that changes how a developer approaches every project that follows. The performance implications of getting that boundary wrong are real and often diagnosed late, after a model has grown complex enough that refactoring it is a significant undertaking. Understanding the principle early saves that work.
The governance discussion is equally useful for the organizations that have overcorrected toward control. Governance that prevents agility does not serve the business any better than no governance at all. The hosts offer a more nuanced position: enough structure to maintain consistency where it matters, enough flexibility to allow the reporting layer to evolve as the business does.
And the argument against canonical model perfectionism is worth hearing repeatedly. Monolithic models built to handle every conceivable use case tend to handle the common ones less well than focused models do. The pragmatic approach the hosts describe produces something that ships, performs, and can be extended over time without requiring a rebuild every time requirements change.
