Forum Discussion
Best Approach for User Access Table with Different Refresh Frequencies
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.
Hi bdpr_95,
Why not just use directlake for both the user access table and the fact tables? This would be the approach I would use.
This avoids the complexity of maintaining composite models, and if in the future the business decides that these fact tables need to be refreshed more often, then it allows for this without any additional changes.
This also solves problem 2 as the semantic model will always be up to date with the tables.
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
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.
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.