TL;DR
Power BI data modeling best practices in 2026 start with picking the right storage mode first. Import mode still fits most reporting workloads. Direct Lake now comes in two versions, Direct Lake on OneLake and Direct Lake on SQL, each with different fallback rules. Every model should still follow a star schema with clean fact and dimension tables. Cut model size before touching DAX. Calculation groups and field parameters replace dozens of duplicate measures. Row-level and object-level security belong inside the model, not scattered across reports. Copilot can draft simple DAX and summarize a model, but every output still needs a human check.
Power BI models built two years ago do not run the way models run today. Direct Lake changed how tables load into memory, and Fabric renamed datasets to semantic models. Power BI Premium capacity is being phased out in favor of Fabric SKUs, and Copilot now sits inside the modeling workflow itself.
Most published guidance on Power BI data modeling still describes 2023. Star schema principles have not moved. Everything built around them, storage modes, security, deployment, and AI assistance, has.
This guide covers what actually matters for a model built in 2026, from Direct Lake to calculation groups. In this article, we’ll cover storage mode selection, star schema design, security, governance, and where Copilot helps.
Key Takeaways Power BI now uses two Direct Lake modes, Direct Lake on OneLake and Direct Lake on SQL, and each behaves differently when data cannot load directly. Star schema design is still the foundation of a fast Power BI model, and Microsoft’s own guidance treats it as non-negotiable for anything beyond a trivial report. Direct Lake on OneLake and Direct Lake on SQL fail differently; only one of them falls back to DirectQuery when it hits something it can’t read Calculation groups and field parameters cut measure count dramatically and should replace most manually duplicated time intelligence measures. Copilot for Power BI can draft DAX and summarize models, but Microsoft’s own documentation lists real limitations around variables, hidden objects, and newer functions.
Power BI Data Modeling In 2026: What Actually Changed Power BI stopped being a standalone reporting tool once Fabric absorbed it into a single analytics platform. That shift changed vocabulary, storage architecture, and licensing all at once, and each of those changes has a direct effect on how a model should be designed.
1. Semantic Models Replaced The Old Dataset Model Microsoft renamed the Power BI dataset to semantic model inside the Fabric platform , and the name is not cosmetic. A semantic model in Fabric can serve multiple reports, connect through different storage modes on different tables, and get promoted or certified independently of any single report. Anyone still designing around the old one dataset, one report mental model is missing where governance and reuse actually happen now.
2. Direct Lake Now Comes In Two Variations Direct Lake used to be one storage mode. As of 2026 it splits into Direct Lake on OneLake and Direct Lake on SQL , per Microsoft’s own Fabric documentation, and the two behave differently. OneLake pulls from any Fabric Delta table and never falls back to DirectQuery, while Direct Lake on SQL reads through one lakehouse or warehouse and falls back the moment it hits a SQL view or an access rule it cannot resolve directly.
3. Power BI Premium Capacity Is Being Retired Premium per-capacity SKUs (the P1 through P5 tiers) are being retired in favor of Fabric capacity SKUs (F2 through F8192), per Microsoft’s Direct Lake documentation . Every new Direct Lake deployment should plan around an F-SKU rather than a legacy P-SKU, since new features and guardrail updates land on the Fabric side first.
4. What This Means For Modeling Decisions Today None of this changes why star schema works. It changes which storage mode makes sense, how refresh gets scheduled, and how Power BI Premium licensing decisions get made for the next model a team builds. Teams still weighing Microsoft Fabric against standalone Power BI , or planning a broader Microsoft Fabric adoption timeline, should fold these modeling decisions into that same planning conversation from the start.
Not Sure Which Storage Mode Fits Your Data? Kanerika’s Power BI and Fabric team reviews existing models and data volumes, then recommends whether Import, Direct Lake, or a composite approach fits before rebuilding a single table.
Schedule a Meeting →
Choosing The Right Storage Mode For Your Semantic Model Storage mode is the single decision that shapes everything downstream, refresh strategy, security options, and how big a model can grow before it needs a redesign. Getting this choice wrong is far more expensive to fix later than a messy measure name.
1. Import Mode Still Wins For Most Reporting Workloads Import mode compresses data into the VertiPaq in-memory engine, and for the majority of business reporting it remains the fastest and most flexible option. It supports calculated columns, hybrid tables, and user-defined aggregations that Direct Lake still does not. Teams without a Fabric capacity, or without a clean upstream lakehouse to point at, should default here first.
2. Direct Lake For Large, Frequently Changing Fabric Data Direct Lake makes sense when data volumes are too large to reasonably import on a schedule, or when the business needs near-real-time numbers without running a full refresh cycle. It skips the data copy step entirely and instead reads Delta tables straight from OneLake, refreshing only metadata rather than the underlying rows. Teams keeping an Import model instead should look at incremental refresh in Power BI before assuming a full daily reload is the only option.
3. DirectQuery For Governed Or Truly Live Sources DirectQuery still has a place when row-level security must live at the source database or when regulatory rules block any copy of the data from existing elsewhere. Query performance depends entirely on the source database, so DirectQuery on an unoptimized warehouse feels slow no matter how clean the star schema in Power BI looks on paper.
4. Composite Models To Mix Modes Inside One Semantic Model A composite model combines storage modes inside a single semantic model, pairing a Direct Lake fact table with an Import dimension table, for example. Composite models in Power BI give teams a middle path when part of the data needs Direct Lake scale and part needs Import mode flexibility, though Direct Lake on SQL cannot mix with DirectQuery or Dual mode tables in the same model the way Direct Lake on OneLake can. Teams running a Fabric data warehouse alongside Power BI, or comparing how a Snowflake semantic layer handles the same governed-metrics problem, will recognize the same composite-versus-single-mode tradeoff playing out on other platforms.
Getting the storage mode right sets the ceiling for everything the model can do. The next question is what the model looks like underneath, and that comes down to schema design.
Storage Mode Data Source Refresh Behavior RLS Support Best For Import Any connector Full data copy on schedule Full support Most standard reporting Direct Lake on OneLake Any Fabric Delta table source Metadata only, near-instant Supported, fixed identity recommended Large Fabric-native data with frequent change Direct Lake on SQL Single lakehouse or warehouse Metadata only, falls back to DirectQuery Supported, falls back on SQL views Fabric warehouse data with occasional complex views DirectQuery Any DirectQuery connector No copy, live query per interaction Full support at source or model Governed, truly real-time sources
Star Schema: The Foundation Of Power BI Data Modeling Star schema design predates Power BI by decades, and it remains the model architecture Microsoft’s own guidance recommends for anything beyond a single flat table report. It works because the VertiPaq engine compresses and queries denormalized fact and dimension tables far more efficiently than a normalized, snowflaked structure built for a transactional database. The same principles show up across any business intelligence architecture built on a governed data warehouse architecture , tracing back to the dimensional modeling work Ralph Kimball formalized decades before Power BI existed.
1. Separate Fact Tables From Dimension Tables A table’s role as fact or dimension is not a property anyone sets directly. Per Microsoft’s own star schema guidance , it is determined by relationship cardinality, where the one side of a relationship is always the dimension and the many side is always the fact. Mixing both roles into a single wide table defeats the compression the engine relies on, and it makes every future relationship harder to reason about.
2. Keep Fact Tables At A Single Consistent Grain Every row in a fact table should represent the same level of detail, one order line, one transaction, one sensor reading. A fact table that mixes daily summaries with individual transactions will produce numbers that look correct in isolation and wrong the moment two visuals compare totals at different grains. This single mistake accounts for a large share of the “the numbers don’t match” tickets a BI team fields.
3. Avoid Snowflaking Dimensions Unless A Real Reason Exists Snowflaking splits a dimension into multiple related tables to reduce redundancy, the way a relational database designer would normalize customer and region into separate tables. Power BI rarely benefits from this. The extra joins slow query performance without meaningfully shrinking a well-compressed dimension table, so flattening a snowflaked dimension into one denormalized table is almost always the better call for reporting.
4. Turn Off Bidirectional Filtering By Default Bidirectional relationships let filters flow both directions between two tables, and they look convenient until they create ambiguous filter paths or silently double-count values in a many-to-many scenario. Set relationships to single-direction filtering as the default, and reach for bidirectional or many-to-many only when a specific, well-understood use case actually requires it, such as a genuine many-to-many bridge table pattern.
Related reading: for teams weighing normalized versus denormalized dimension design directly, star schema versus snowflake schema breaks down the tradeoff with concrete examples, and Power BI data modeling tools covers the editors teams use to build and maintain these schemas at scale.
Star Schema in Power BI: A 6-Step Power Query Guide A step-by-step walkthrough of building fact and dimension tables in Power Query, from raw source data to a working star schema, for readers who want the hands-on version of the principles above.
Read the Full Guide →
Solving Measure Sprawl With Calculation Groups And Field Parameters Most large Power BI models accumulate duplicate measures over time, one for current period, one for prior period, one for year over year, repeated across every base measure in the model. Calculation groups and field parameters both solve this, but they solve different problems.
1. Calculation Groups For Time Intelligence Variants A calculation group applies a single DAX expression, current period, prior period, percent change, across every measure in the model dynamically, instead of requiring a separate physical measure for each variant. A model with twenty base measures and five time intelligence variants each would otherwise need a hundred separate measures; a single calculation group with five calculation items handles the same coverage. Reusable logic like this pairs naturally with Power BI DAX user-defined functions , which solve the same duplication problem for calculation logic that does not fit the calculation-group pattern.
2. Field Parameters For Dynamic Report Switching Field parameters let a report user swap which field or measure a visual displays through a slicer, switching a chart between revenue, units, and margin without building three separate visuals. They solve a report-interactivity problem rather than a measure-duplication problem, which is the main distinction from calculation groups. Teams building on Fabric warehouse or lakehouse data directly will find the same pattern covered in field parameters in Microsoft Fabric .
3. When The Two Techniques Overlap Some scenarios, like letting a user pick both a metric and a time comparison from slicers, genuinely need both techniques working together. In that combined case, field parameters control which measure or column a visual reads, and a calculation group applies the time-based transformation on top of whatever the field parameter currently selects.
Both techniques exist to keep a model maintainable as it grows, which matters just as much for security as it does for measure count. A model with a hundred duplicate measures is hard to secure correctly for the same reason it is hard to maintain.
Capability Calculation Groups Field Parameters Solves Duplicate measure logic (time intelligence, currency conversion) Dynamic axis or measure switching in a visual Applies To Any measure in the model automatically Whatever fields are added to the parameter Requires Tabular Editor or DAX query view to author Native Power BI Desktop feature Typical Use Current vs prior period, YTD, running total Metric selector slicers, dynamic chart axes
Security In Power BI Data Modeling: Row-Level And Object-Level Access Security decisions belong inside the semantic model itself, not bolted onto individual reports after the fact. A model with security built in stays consistent no matter how many reports eventually connect to it.
1. Static Versus Dynamic Row-Level Security Static RLS assigns a fixed DAX filter to a security role, useful when access rules rarely change. Dynamic RLS filters data based on the logged-in user’s identity against a table of user-to-data mappings, which scales far better across an organization with hundreds of users and changing territory or account assignments. Power BI row-level security , per Microsoft’s own Fabric RLS documentation , supports both patterns natively.
2. Object-Level Security For Columns And Tables Row-level security controls which rows a user sees. Object-level security, documented separately in Microsoft’s OLS guidance , controls which tables and columns a user can see at all, useful for hiding sensitive fields like compensation from users who otherwise have broad row access. A mature data access governance program treats both layers as one combined control, configured together rather than patched in separately over time.
3. Fixed Identity On Direct Lake Semantic Models Direct Lake semantic models support both RLS and OLS, but Microsoft strongly recommends a fixed identity cloud connection over the viewer’s own identity when RLS is in play, since it produces more predictable query behavior against OneLake. Skipping this step is a common source of intermittent access errors that are hard to reproduce and diagnose later. Any team writing this into a broader Microsoft Fabric governance plan should document the fixed identity requirement alongside the rest of the data governance framework that RLS and OLS decisions feed into.
Security done correctly at the model level also determines how cleanly data governance best practices translate from policy documents into something enforced automatically. Otherwise a compliance team ends up auditing it manually after the fact.
The Current State Of Copilot In Power BI Data Modeling Copilot for Power BI now sits directly inside the modeling workflow, well beyond report authoring alone. Microsoft’s own documentation stays candid about where it still falls short, and treating Copilot as a full replacement for modeling judgment is the fastest way to ship a broken measure straight into production.
1. What Copilot Handles Well Right Now Copilot performs reliably on bounded, well-scoped tasks: summarizing what a semantic model contains, drafting a first pass at a straightforward DAX query, or generating narrative text for a report. Copilot in Microsoft Fabric requires a paid Fabric or Premium capacity, per Microsoft’s Copilot requirements documentation , and it will not activate at all on trial or free capacity tiers.
2. Where Copilot Still Gets The Model Wrong Microsoft’s own guidance on using Copilot with semantic models lists specific, documented failure modes: Copilot cannot see the DAX behind existing measures or hidden objects when connected live to a shared model, it struggles with variable reuse in generated DAX, and it is more likely to make mistakes on newer DAX functions the training data covers less thoroughly. Answers to data questions are also explicitly nondeterministic, meaning the same prompt against the same model is not guaranteed to return the same result twice.
3. How To Prepare A Model So Copilot Performs Better Copilot’s accuracy depends heavily on how well the model itself is documented. Clear table and column names, sensible field synonyms, and hidden technical helper columns all measurably improve output quality, which means the modeling discipline covered earlier in this guide is also, indirectly, Copilot preparation. A poorly modeled table produces poor Copilot answers regardless of how good the prompt is.
The realistic read for 2026 is that Copilot speeds up the first draft of a query or a summary. A human who understands the model still needs to verify the result before it reaches a dashboard, the same discipline that AI-generated Fabric agents and copilots require across the rest of the platform.
Governance And Deployment: The Final Layer Of Power BI Data Modeling A well-designed model still fails organizationally if five different teams each build their own copy of the same logic. Governance and deployment discipline are what keep one clean model from splintering into ten inconsistent ones.
1. Use Deployment Pipelines For Dev, Test, And Production Power BI deployment pipelines now support anywhere from two to ten stages rather than a fixed three, per Microsoft’s Fabric deployment pipelines documentation , which gives larger organizations room for a real staging environment between test and production. Note that a semantic model using DirectQuery or composite mode with auto date/time tables is not supported in a deployment pipeline, one more reason to disable auto date/time as covered earlier.
2. Certify One Semantic Model Instead Of Multiple Copies Certifying and promoting a single semantic model as the source of truth for a given subject area discourages the copy-and-tweak pattern that produces conflicting numbers across departments. Every additional uncertified copy of a model is another place a metric definition can quietly drift from the original.
3. Take Advantage Of Granular Refresh Controls Power BI’s August 2026 update, according to Microsoft’s own release notes , added three distinct refresh options in the service: refresh schema and data, sync schema only, or refresh data only, along with table-level refresh. That level of control lets a team refresh a single changed table instead of the entire model, cutting unnecessary load on both the source system and the Fabric capacity.
4. Document Ownership Before The Model Sprawls A named owner, a change log, and a clear promotion path from draft to certified all sound like overhead until a model has been in production for a year and nobody remembers why a specific measure was written the way it was. Self-service business intelligence works best when it operates inside that kind of governed structure, not as a substitute for it. Microsoft Fabric capacity planning should account for how many certified models a given capacity actually needs to support.
Power BI Data Modeling: How Kanerika Cuts Manual Reporting Time Kanerika is a Microsoft Solutions Partner for Data and AI with Analytics Specialization, a Microsoft Fabric Featured Partner, a Databricks Consulting Partner, and a Snowflake Select Tier Partner. The firm’s Chief Analytics Officer, Amit Chandak, holds a Microsoft MVP designation for the Power BI product area. That combination of partner-level standing and in-house product expertise shapes how Kanerika approaches Power BI engagements from the first workshop onward.
Kanerika treats data modeling as the foundation of a reporting engagement, not a step to rush past on the way to dashboard design. Every project starts by mapping what each stakeholder group actually needs from the reporting layer, then builds a star schema and a governed semantic model around those requirements before a single visual gets built. That sequencing avoids the common failure pattern where a team builds dashboards on top of an unstable model and spends months afterward reconciling numbers that never should have disagreed in the first place.
The firm’s data analytics practice applies this same modeling discipline across industries with heavy compliance and reporting demands, financial services, healthcare, and manufacturing among them, where a single certified semantic model has to serve internal teams, external stakeholders, and regulators without producing three different versions of the same number. The engineering team makes storage mode and security decisions based on each client’s actual data volume and refresh needs, rather than defaulting to one approach across every engagement.
Case Study: Performance Gain With Cognos To Power BI Migration A global retail enterprise running hundreds of BI and performance reports across store operations, procurement, finance, logistics, and marketing needed to move off static Cognos dashboards without losing years of embedded report logic. The engagement centered on migrating the underlying data structures and formula logic first, then rebuilding the report layer on top.
Client’s Challenges
Ran limited, static Cognos dashboards that slowed decision-making and offered no real interactivity for business users Carried high operational costs from legacy BI licensing that constrained scalability and flexibility Faced inconsistent data access across departments, causing delays and duplicated reporting effort at the business-unit level
Kanerika’s Solutions
Migrated to Power BI using automated accelerators that replicated existing data structures and converted legacy formulas into DAX rather than rebuilding logic by hand Reduced licensing and maintenance overhead by retiring the legacy Cognos environment once the Power BI model was validated Centralized data accessibility across business units, replacing fragmented departmental reporting with one governed source
Business Results
65% performance gain across BI operations 27% reduction in overall BI cost 2X Scalable Data and BI Capabilities
Wrapping Up A Power BI model built on 2023 assumptions can still run in 2026, but it leaves real performance, security, and governance capability unused. Storage mode selection now has more options than it used to, star schema discipline has not changed at all, and Copilot helps most when the underlying model is already well built. Getting the model right first makes every report, refresh, and security rule that follows simpler to build and easier to trust.
Frequently Asked Questions
What are the most important Power BI data modeling best practices in 2026? The core practices remain storage mode selection and star schema design, with two additions specific to 2026: choosing between Direct Lake on OneLake and Direct Lake on SQL, and building models that Copilot can interpret accurately. A well-modeled semantic model with clean fact and dimension tables outperforms almost any amount of DAX optimization layered onto a poorly structured one.
Should a Power BI semantic model use Direct Lake or Import mode? Import mode fits most standard reporting workloads and supports features Direct Lake still lacks, including calculated columns and hybrid tables. Direct Lake makes more sense for large, frequently updated Fabric-native data where a full import refresh would be too slow or too resource-intensive to run on a useful schedule. Storage mode is set per table and documented in Microsoft’s semantic model modes guidance, so many models genuinely benefit from combining more than one mode through a composite model.
Why is star schema still recommended for Power BI in 2026? Star schema aligns directly with how the VertiPaq engine compresses and queries data, and that architecture has not changed even as storage modes have. Microsoft’s own current guidance treats star schema as the default recommendation for any model beyond a single flat table, separating clean fact tables from dimension tables connected through single-direction relationships.
What is the difference between Direct Lake on OneLake and Direct Lake on SQL? Direct Lake on OneLake connects to Delta tables across any Fabric data source and does not fall back to DirectQuery under any circumstance. Direct Lake on SQL connects through a single lakehouse or warehouse’s SQL analytics endpoint instead. It automatically falls back to DirectQuery when it encounters something it cannot read directly, such as a SQL view or column-level access control.
Do calculation groups replace field parameters in Power BI? No, they solve different problems and often work together. Calculation groups, documented directly by Microsoft, eliminate duplicate measures for variants like time intelligence, while field parameters let a report user dynamically switch which field or measure a visual displays. A report with both a metric selector and a time comparison slicer typically needs both techniques at once.
How does row-level security work with Direct Lake semantic models? Direct Lake supports both static and dynamic row-level security the same way Import mode does. Microsoft recommends a fixed identity cloud connection over the individual viewer’s identity when RLS is active, since it produces more predictable results against OneLake. Skipping the fixed identity setup is a common source of intermittent access issues.
Can Copilot build or fix a Power BI data model automatically? Not reliably on its own. Copilot can draft simple DAX queries and summarize what a model contains. Microsoft’s own documentation confirms it cannot see the DAX behind hidden measures on a live connection, struggles with variable reuse, and is prone to errors on newer DAX functions. Every Copilot-generated measure or query still needs a human review before it ships to a dashboard.
How often should a Power BI semantic model be refreshed? It depends on the storage mode and the business need for data freshness. Import models typically refresh on a fixed schedule, from hourly to daily, while Direct Lake models can update automatically through metadata framing without a traditional refresh cycle at all. Power BI’s August 2026 update also added table-level and schema-only refresh options, letting teams refresh only what actually changed instead of the entire model.
