Forum Discussion
RLS implementation under direct Lake connectivity
Hi,
I'm reaching out to hear perspectives and to better understand from the community, the nuances of RLS implementation under Direct lake connectivity in Power BI semantic models.
Context: Building a data product using a Medallion architecture (Bronze, Silver, Gold) where the Gold layer resides in a Fabric Warehouse. Consumption is planned in Power BI using Direct Lake connectivity.
Having seen few reference, it appears that enforcing RLS (dynamic) strictly at the Power BI Semantic Model layer is a better choice. This is to prioritize Interactive Performance (Direct Lake) over Security Centralization (Warehouse RLS).
The Reasoning: Implementing RLS at the Warehouse/SQL Analytics Endpoint layer triggers an automatic DirectQuery fallback. This prevents the VertiPaq engine from loading Delta files into memory, negating the performance benefits of Direct Lake.
If RLS exists at both layers, the system performs a union of roles at the source and an intersection with the semantic model roles. The most restrictive rules prevail, but at the cost of losing Direct Lake speed.
Looking forward to hearing prespectives.
Your reasoning is solid and aligns with the current Microsoft guidance. Here's a more complete picture to round it out:
Your core point is correct — RLS defined at the Warehouse/SQL Analytics Endpoint level causes a DirectQuery fallback because Direct Lake can't push row-level security predicates down to VertiPaq from an external SQL security layer. The moment Direct Lake detects it needs to enforce SQL-layer row filters, it falls back to DirectQuery against the SQL Analytics Endpoint, losing the in-memory performance advantage entirely.
RLS at the semantic model layer is the right call for Direct Lake, and it's exactly what Microsoft recommends. Dynamic RLS using USERPRINCIPALNAME() or USERNAME() in DAX roles works natively within the VertiPaq engine without triggering fallback, as long as the filtering happens on tables that are loaded into the Direct Lake frame.
A few nuances worth knowing:
One thing to watch is that Direct Lake has its own concept of "fallback" triggers beyond just RLS — things like unsupported data types, very large string columns, or certain complex queries can also cause fallback. It's worth monitoring the fallback rate in the Fabric Capacity Metrics app after deployment to confirm you're genuinely staying in Direct Lake mode.
Another consideration is that semantic model RLS doesn't protect data if someone queries the Warehouse directly via SQL (e.g., through the SQL Analytics Endpoint or a notebook). If your Gold layer contains sensitive data, you might still want Warehouse-level security for those access paths, while accepting that those users won't go through the semantic model at all. The two security layers serve different access channels.
Finally, if you have very complex, dynamic RLS rules (like territory hierarchies or organizational rollups), make sure the security table itself is also in the Direct Lake frame — if it has to fall back to query the security mapping, you lose the benefit there too.For Direct Lake over a Warehouse/SQL endpoint, applying RLS at the source will typically force DirectQuery fallback, which removes the main performance benefit. That’s why, in most cases, semantic model RLS is the preferred approach for interactive reporting.
However, this comes with a trade-off: model-level RLS only secures access through Power BI, not across other consumers of the same data. If you need centralized, cross-engine security, you’ll have to accept either performance impact or consider alternatives like OneLake-based architectures.
In short:
- Performance priority → RLS in semantic model
- Security centralization → RLS at data layer (with trade-offs)
5 Replies
For Direct Lake over a Warehouse/SQL endpoint, applying RLS at the source will typically force DirectQuery fallback, which removes the main performance benefit. That’s why, in most cases, semantic model RLS is the preferred approach for interactive reporting.
However, this comes with a trade-off: model-level RLS only secures access through Power BI, not across other consumers of the same data. If you need centralized, cross-engine security, you’ll have to accept either performance impact or consider alternatives like OneLake-based architectures.
In short:
- Performance priority → RLS in semantic model
- Security centralization → RLS at data layer (with trade-offs)
Thank you for the response cengizhanarslan
This is in line with what I could find out. I am interested to know about your pointer on "OneLake-based architectures". Could you please elaborate if possible? How does this fit in this context. Thank you!
Your reasoning is solid and aligns with the current Microsoft guidance. Here's a more complete picture to round it out:
Your core point is correct — RLS defined at the Warehouse/SQL Analytics Endpoint level causes a DirectQuery fallback because Direct Lake can't push row-level security predicates down to VertiPaq from an external SQL security layer. The moment Direct Lake detects it needs to enforce SQL-layer row filters, it falls back to DirectQuery against the SQL Analytics Endpoint, losing the in-memory performance advantage entirely.
RLS at the semantic model layer is the right call for Direct Lake, and it's exactly what Microsoft recommends. Dynamic RLS using USERPRINCIPALNAME() or USERNAME() in DAX roles works natively within the VertiPaq engine without triggering fallback, as long as the filtering happens on tables that are loaded into the Direct Lake frame.
A few nuances worth knowing:
One thing to watch is that Direct Lake has its own concept of "fallback" triggers beyond just RLS — things like unsupported data types, very large string columns, or certain complex queries can also cause fallback. It's worth monitoring the fallback rate in the Fabric Capacity Metrics app after deployment to confirm you're genuinely staying in Direct Lake mode.
Another consideration is that semantic model RLS doesn't protect data if someone queries the Warehouse directly via SQL (e.g., through the SQL Analytics Endpoint or a notebook). If your Gold layer contains sensitive data, you might still want Warehouse-level security for those access paths, while accepting that those users won't go through the semantic model at all. The two security layers serve different access channels.
Finally, if you have very complex, dynamic RLS rules (like territory hierarchies or organizational rollups), make sure the security table itself is also in the Direct Lake frame — if it has to fall back to query the security mapping, you lose the benefit there too.Thank you for an elaborative answer Juan-Power-bi. So it seems like there is a trade off. Either have performance of directly and implement row level security at the semantic model layer or centralized security by implementing heated storage (warehouse) level but risk direct lake fallback into direct query. Is there no other alternative?
Thank you!
ankurarora1418, thanks for bringing this great discussion out! I believe the current answers already cover it well, so I wanted to challenge the idea of using Direct Lake against Data Warehouse in the medallion architecture.
The main benefit of Direct Lake is to read the data live, right? Which has a perfect sense for Streaming database or, for instance SQL DB which continiously gets new transacations. But how often do you update your gold Data Warehouse? Once a day, once every hour? If so, why not to use Import mode?
