Power BI Direct Lake calculated columns arrive
Guy in a Cube shows Direct Lake calculated columns in Power BI and explains where they fit, how they work, and their performance tradeoffs.
Key insights
- Guy in a Cube shows Direct Lake calculated columns in Microsoft Fabric.
- The feature is described as unmaterialized and tied to User Context.
- It works on Direct Lake on OneLake, not Direct Lake on SQL.
- The video covers expression context, user culture, and localization.
- Performance is a key factor, and source-side logic is still preferred.
Guy in a Cube recently published an 8-minute video in which Patrick LeBlanc walks through Direct Lake calculated columns in Power BI. The main takeaway is simple: the feature fills a reporting gap when you need a column in the semantic model, but it comes with context and performance tradeoffs that matter before you use it.
The video uses a real reporting scenario where a calculated column was needed for report categorization, but updating the source warehouse was not an option. From there, Patrick shows how the feature behaves in Microsoft Fabric, how it differs between Direct Lake on SQL and Direct Lake on OneLake, and why these columns are not the same as measures.
What's new
Direct Lake calculated columns are described in the video as finally available for use in Microsoft Fabric. The capability is called out in the source notes as Direct Lake calculated columns (unmaterialized), which matters because the column is not stored in the same way as a traditional Import-model calculated column. Instead, it is evaluated when needed.
The video also highlights a practical distinction: the feature applies to Direct Lake on OneLake, while Direct Lake on SQL does not support calculated columns that reference Direct Lake data. That makes storage mode an important part of the decision, not just the DAX expression itself.
Why it matters
This is relevant to Power BI authors and Fabric users who need a small transformation in the semantic model without changing upstream data. The scenario in the video is a good example: when another team owns the warehouse or when the source cannot be changed quickly, a calculated column can solve a reporting problem inside the model.
For admins and model builders, the feature adds flexibility, but it also adds responsibility. The video stresses that performance should be part of the decision-making process, and the research notes say source-side implementation is usually preferred. In other words, this is useful when the model needs it, not as a default replacement for upstream shaping.
The feature is also relevant for cases where the result needs to respond to the current user. The notes mention user-aware functions such as , , and , which points to localization and other context-sensitive scenarios.
If you follow Power BI and Fabric updates, this is the sort of capability that changes what can be done directly in a semantic model. For readers who want more context on the platform around it, HubSite 365 also covers Power BI topics more broadly.
How it works
Patrick’s walkthrough starts with enabling the preview capability in Power BI Desktop, then opening a semantic model that uses Direct Lake on OneLake tables. From there, the workflow is straightforward: select the relevant table, choose New column, and enter a DAX expression.
- Enable the Direct Lake calculated-columns preview feature in Power BI Desktop.
- Open or connect to a semantic model that uses Direct Lake on OneLake.
- Select a table in Model, Table, or Report view.
- Choose New column.
- Write and validate the DAX expression.
- Test the result before publishing the semantic model.
The key technical detail is the expression context. The research notes say these calculated columns currently support only User Context. That means the result can respond to information about the current user, including culture-related behavior for localization.
The video chapters also point to a step-by-step look at creating a first Direct Lake calculated column, building an event shift column, and testing localization changes. Those examples reinforce the idea that the feature is about targeted model logic, not broad row-by-row transformation inside the warehouse.
Limitations and open questions
The source material is clear that the feature is in preview, so it should be treated as a capability to test, not something to assume is ready for every production model. The exact availability may depend on the Power BI Desktop version, tenant rollout, semantic-model configuration, and whether the model is truly using Direct Lake on OneLake.
The notes also say the columns are unmaterialized. That means they are evaluated when needed and cannot be used as relationship keys. The video frames this as an important limitation, especially for model design choices that depend on persisted columns.
Another boundary is the difference between Direct Lake on OneLake and Direct Lake on SQL. The material states the new capability applies to the OneLake path, while SQL support does not cover the same scenario. What the material does not fully verify is how all preview edge cases behave across versions or tenant settings.
Finally, the video says user-aware functions can produce context-sensitive results, but the material does not claim that every DAX function is supported in this mode. Readers should treat the supported-expression surface as narrower than a full Import-model calculated column.
Sources
Frequently asked questions
Are Direct Lake calculated columns the same as measures?
No. The source material says they are not the same as measures, and the columns are evaluated in context rather than treated as a measure calculation.
Do they work with Direct Lake on SQL?
The material says the new calculated-column capability applies to Direct Lake on OneLake. It also says Direct Lake on SQL does not support calculated columns that reference Direct Lake data.
Can these columns be used as relationship keys?
No. The research notes say the columns are unmaterialized and cannot be used as relationship keys.
What kind of scenarios are they meant for?
The video uses a report categorization case where the source warehouse could not be updated. The notes also mention user-aware and localization scenarios.