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.