By: Audrey Gerred

After almost a decade of working with Power BI and now Microsoft Fabric —earning certifications, community recognition, and the “Super User” rank in the Fabric Community forums — I’ve seen a pattern emerge (#AuDHD #iykyk): the tools are powerful, flexible, and forgiving, but¹ that flexibility often tempts users into practices that feel convenient or familiar² in the moment but sabotage scalability, performance, and clarity in the long run (you know… in production).

So, let’s talk about the difference between can and should³.

1. Denormalized Wide Tables: Yes, You Can. No, You Shouldn’t

Power BI will not stop you from building a single flat table with all your facts and dimensions crammed together. It’ll even render visuals. But ignoring star schema design is like wiring a house without a circuit breaker—works until something overloads. Just wait until you want or need to scale, optimize, or troubleshoot…

• Why it matters: Star schema supports efficient relationships, better compression⁴, and clearer semantic modeling.
• What to do instead: Normalize your data⁵. Use dimension tables⁶. Respect granularity⁷.

2. One Model Per Report (1:1): Tempting, But Misguided

Sure, you can build a separate model for each report. Power BI will not even speak up and object. But this leads to duplication, inconsistent logic, and a maintenance nightmare.

• Why it matters: Centralized models promote reuse, governance, and consistency. Who doesn’t want that?
• What to do instead: Build reusable semantic models and connect multiple reports to them.

3. Implicit Measures: Easy Doesn’t Equate to Right

Power BI lets you drag and drop fields into visuals and auto-aggregates them. That’s implicit measures. But they’re fragile, opaque, and often misleading.

• Why it matters: Explicit measures are transparent, reusable, and easier to debug.
• What to do instead: Define your measures in DAX. Name them clearly. Own your logic.

4. Measures Table: Optional, But Essential

Technically, you don’t need a dedicated measures table⁸. But skipping it is like tossing all your spices into one drawer with no labels.

• Why it matters: A measures table improves discoverability, organization, and user experience.
• What to do instead: Create a measures table. Use folders if desired. Include descriptions (HINT: Generating descriptions is a great use of Copilot).

5. Renaming Fields in Power BI: You Can, But It’s the Wrong Layer

Renaming columns in Power BI is allowed in the sense that it won’t stop you from doing it — but it’s a semantic patch over a structural problem.

• Why it matters: Renaming at the lakehouse or warehouse level ensures consistency across tools and teams and minimizes repetitive work downstream.
• What to do instead: Clean and rename upstream in views. Let Power BI reflect the source, not override it.

6. Direct Query ≠ Live Data

It is a very common misconception that Direct Query equates to real-time or streaming data. Direct Query feels “live,” but it’s only as fresh as the source.

• Why it matters: If your source updates once a day, your Direct Query visuals show stale data until the next load.
• What to do instead: Know your refresh cadence. Use Direct Query when true real-time/streaming is needed.

7. Direct Query for Everything? Please Don’t.

Power BI won’t stop you from using Direct Query for every model. But performance will. And then the complaints from users will.

• Why it matters: Direct Query introduces latency, limits DAX functionality, and depends heavily on source performance⁹.
• What to do instead: Define clear guidelines. Use Direct Query only when:
  • Data must be real-time and source supports it
  • Security requires source-level control¹⁰
  • Dataset size exceeds import limits¹¹

Even then, be sure to add manual aggregate tables and/or create hybrid tables whereby part of the table is in archive, part is import, and part is hybrid.

Final Thought: Tools Don’t Impose Wisdom—You Do

Power BI and Fabric are generous. They’ll let you build almost anything. But they won’t stop you from building it badly. That’s where experience, governance, and architectural discipline come in.

So next time you’re tempted to take the shortcut the tool allows, ask yourself: Just because I can… should I?

1. But, with great power comes great responsibility! In this case, responsible, sustainable, optimized, re-useable, and scalable semantic modeling ↩︎
2. We’ve always done it that way ↩︎
3. I say ‘can vs should’ because as a neurodivergent woman, I know saying ‘dos and don’ts’ tends to ruffle feathers ↩︎
4. A star schema model can get compression rates of up to 10x, compared to flat/denormalized tables which only yield 2-4x compression ↩︎
5. Exclamation point! ↩︎
6. Exclamation point! ↩︎
7. Exclamation point! ↩︎
8. Ditto for parameter table for dimension fields, parameter table for measures, and calculation groups (especially for time intelligence) ↩︎
9. And, still following all other Power BI best practices ↩︎
10. In other words, not because you don’t want to re-define it again in Power BI ↩︎
11. And, ensuring you are following star schema – if your model size exceeds the SKU size limitations and does not follow star schema, switching to Direct Query is not a solution. Star schema is. ↩︎