Forum Discussion
RLS usage in PowerBI - Optimization
Yes it can impact performance, and with DirectQuery you’ll feel it immediately, because every visual interaction sends queries back to Databricks, and the row filter is applied on every query.
If your Databricks row filter depends on CURRENT_USER() / Entra ID mapping, the engine often can’t reuse results across users, so you get:
less cache reuse
more time spent evaluating security predicates
more expensive scans/joins if the filter is not highly selective
It’s usually fine if the security filter is selective (cuts data down early) and your tables are designed for it (partitioning / clustering on geography keys, good file sizes, stats). It becomes slow when the filter is complex or applied late (e.g., after joins), or when it forces the query into less optimal plans.
What to watch / do:
Make sure the filter column (geography key) is a strong pruning column (partition/cluster it).
Prefer filtering on a simple key (RegionID) rather than text fields.
Keep the security mapping table small and broadcast-friendly.
In Power BI, avoid “chatty” visuals (high-cardinality breakdowns) and reduce cross-filtering where possible.
Hii JothyGanesan
With DirectQuery, the row-level security defined in Databricks (row filters / Unity Catalog) is applied at query time for every user. Power BI simply passes the user context (Entra ID) to Databricks, and Databricks enforces the filter before returning data. This means performance does depend on the RLS filter, but it does not add extra overhead in Power BI itself. To keep performance optimal, ensure the RLS columns are well-partitioned, indexed, and included in Databricks optimizations (Z-ORDER, caching). Databricks-side RLS is the recommended and scalable approach for large DirectQuery models.