Forum Discussion

bdpr_95's avatar
bdpr_95
Helper IV
10 months ago
Solved

Best Approach for User Access Table with Different Refresh Frequencies

Hi everyone, I'm working on a use case involving 20 Power BI reports. For 10 of these reports, the fact tables are updated daily, while for the other 10, the fact tables are only updated monthly. M...
Need Help
  • bdpr_95's avatar
    bdpr_95
    10 months ago

    v-echaithra, I plan to use import mode for all tables and configure pipelines to refresh the monthly reports and update the daily user access table.

bdpr_95's avatar
bdpr_95
Helper IV
10 months ago

tayloramy , if I follow your approach, another question I have is about costs. My data source is Snowflake, and I’m concerned about potentially higher costs if I use mirroring, since this could require keeping a Snowflake warehouse running more often. Will I end up paying more because the warehouse needs to be online for data to be mirrored? The way I plan to get the data is through mirroring.

tayloramy's avatar
tayloramy
Super User
10 months ago

Hi bdpr_95, 

 

Personally I would just move the data into Fabric on a monthly schedule, and have the reports sit on the fabric native data. 

 

If you want to do this without a staging approach, and without keeping the snowflake warehouse going for cost reasons, then I would recommend a more complex composite model. 

 

Mirroring does incur costs: https://learn.microsoft.com/en-us/fabric/mirroring/snowflake#mirrored-snowflake-cost-considerations

 

Use import mode for the snowflake data, and direct query for the access control data, and then using a pipeline schedule the refresh monthly: 

https://learn.microsoft.com/en-us/fabric/data-factory/semantic-model-refresh-activity

 

 

Now as ribisht17 pointed out, there are limitations to this approach: 

 

ribisht17 wrote:

Limitations

Model complexity: Relationships between Direct Lake and Import tables can introduce latency or query inconsistencies if not modeled carefully.

Unsupported features (as of Sept 2025):

Drillthrough and Analyze in Excel may not work with Direct Lake.

Calculated columns and Power Query transformations are limited in Direct Lake.

Security modeling: Row-level security (RLS) across mixed storage modes requires careful testing.


These are the reason I would recommend staging the data in Fabric first and then using a full direct lake model. 

 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.