Semantic Model Design Checklist: Performance, Usability and Scale

A well‑designed semantic model in Power BI is more than just a neat star schema. It’s the result of a series of key decisions made early in the design process. Each of these decisions affects not only how readable your reports are and how users perceive them, but most importantly how fast and scalable your semantic model will be, and whether your reports become a powerful asset or a bottleneck for the whole team. 

Below is a compact checklist that structures the key areas you should pay attention to when building models and reports in Power BI. 

Dimensional model 

Starting with the fundamentals: Semantic models based on a classic star schema are easier to maintain, simpler for business users to understand and typically more performant. They also reduce the need for overly complex DAX, because most of the logic comes from a clean data structure. Key principles to remember: 

• Fact tables do not join directly to each other - they only connect to dimension tables. 

• Dimensions act as business‑friendly dictionaries for fact tables and should be understandable to non‑technical users. 

• Custom relationship paths between objects should be implemented via bridge tables, but the default relationship type should still be one‑to‑many. 

Any deviation from these principles should be intentional and well documented - in practice, most business scenarios can be mapped to common dimensional modelling patterns. 

Usability and maintainability 

A technically correct model can still be painful to use if you neglect naming conventions, field organisation or documentation. The result is usually that “temporary” reports end up becoming official solutions, creating a growing risk of errors and high maintenance overhead. To keep it under control, focus on: 

• Consistent naming - tables, columns, measures and other objects should have unambiguous, business‑friendly names. Avoid cryptic abbreviations and overly long names; aim for clarity. 

• Parameterisation in Power Query - parameters for data sources, environments or row limits increase flexibility and make versioning and CI/CD pipelines easier to manage. 

• Measure organisation - keep your core measures in a dedicated measures table and group them into logical display folders, so the model is easy to navigate. 

• Hiding technical fields - technical columns (keys, helper flags, RLS columns, etc.) should be hidden from report authors and end users. 

• Clean, formatted DAX - regularly remove unused code and redundant comments, and keep a consistent DAX formatting style. This makes code reviews, maintenance and debugging much easier. 

A model organised this way is readable not only for the original author, but also for other developers and self‑service users. 

Controlling model size

Model size affects both refresh times and query performance, and in a Fabric context also directly drives compute and storage costs. Even with DirectLake, you should still aim for the smallest and most efficient model possible. 

Practical steps: 

• Correct data types - set proper data types immediately after loading data. Deciding between DateTime and Date has a huge impact at scale, because each type uses a different amount of memory. The same logic applies to numeric types. 

• Fixed decimal instead of floating point - where possible, convert floating‑point columns to fixed decimal or currency types. This usually reduces cardinality and improves compression. 

• Aggregations and granularity - if reporting happens at a monthly level, daily grain may be unnecessary. Consider building a separate aggregated fact table at the right level of detail. 

• Remove unused elements - review your tables regularly and delete attributes and technical keys that are not used anywhere in reports or measures. 

• Filter data as early as possible - the primary way to reduce model size is to filter data at the source. If your report only covers European sales, records from other regions do not have to be loaded into this particular model. 

Decisions made early in designing your model, such as how you structure data and manage its size, will affect performance, refresh times, and costs long after the model is built.