Microsoft Power BI vs Qlik Cloud Analytics

Star schema, advice versus near necessity

Both communities recommend a star schema, and experienced Qlik developers build them as a matter of habit. The difference is how much the tool tolerates when you do not. Power BI’s VertiPaq engine and DAX formula language work best with fact tables surrounded by clean, denormalised dimensions. However, Qlik is more forgiving, allowing for deviations such as Snowflake models and still allowing you to explore freely.

Bring a looser model into Power BI, and whilst it may still function, performance and simplicity suffer. Power BI’s Power Query allow for flattening a Snowflake schema or splitting a bloated table into a proper fact and dimension pair. In Qlik, this is done using the load script. The main difference is that Power BI is less forgiving of poor discipline when modelling.

How the two build relationships

Power BI can detect relationships automatically when data loads, based on column names and data types. In practice I treat that as a first draft. In Model view you still review each relationship and choose the cardinality, the filter direction, and which relationship is active.

Qlik associates tables automatically, and always, on any field with the same name. One shared field gives you a clean association, while two or more shared fields between the same pair of tables create a synthetic key. Experienced Qlik developers handle these deliberately, with renamed fields, qualified names, or composite keys, but a coincidental field name can still link two tables you never meant to link.

Power BI’s approach also forces a conversation Qlik lets you skip: should this relationship filter in one direction or both? Qlik’s associations are not directional, so the question never comes up. In Power BI, you answer it for every relationship.

Bringing fact tables together

Power BI keeps fact tables separate and joins them through shared dimensions. In Qlik, a common habit is to concatenate fact tables at different grains into one larger table, though link tables are just as established a pattern.

Neither approach is wrong. They are different answers to the same problem: how do you let someone compare two things that were never quite measured the same way? Power BI’s version needs a bit more up-front planning around your dimensions, but it tends to age well as more fact tables are added. A single well-built dimension can sit in the middle of sales, stock, and returns at once, tying them together without any of them needing to know about each other.

Restricting what people see

Power BI handles row level security through roles defined against the model, with a DAX filter expression applied at query time. Qlik achieves the same outcome with Section Access, defined in the load script, and applied when a user opens the app. They only ever see the data they are entitled to.

The result for the person viewing the report looks similar either way. Power BI Desktop’s View As Roles option lets you preview the report through each role’s eyes. This makes testing quick and easy to get right first time.

The one piece that barely changes

After several sections of genuine difference, the date table survives the move completely intact. A date table in Power BI and a master calendar in Qlik do precisely the same job, giving every other table a consistent way to talk about time.

Power BI adds one additional step: marking it as a date table. It is not required for every time intelligence approach, but it is recommended. It also helps the built-in DAX time intelligence functions behave predictably. If any piece of Qlik modelling experience transfers without translation, the date table is it.

Watching a selection ripple through the model

This is where I needed the longest to adjust. In Qlik, a selection permeates through the entire app at once, and the green, white, and grey states always show you what is selected and what has been excluded. Set analysis, alternate states, and bookmarks then give you precise control when you need to scope something more tightly.

Power BI works the other way round. Filtering is contained by design and has distinct layers: visual, page, and report level filters in the filter pane, slicers on top, and interactions between visuals that can be set to filter, highlight, or do nothing, controlled through Edit Interactions. You decide where a filter reaches rather than assuming it reaches everywhere.

Once you understand Power BI’s filters, it is a granular and deliberate system. Before it clicks, there is a genuine moment of confusion when a filter you expected to apply everywhere turns out to be scoped to a single visual. I also took longer than expected to stop looking for that all-over green and grey feedback every time I clicked something.