Row-level security restricts access to records through filters evaluated during query or policy execution. In a lakehouse, it belongs to the consumption and federation path, where controls should align with governance policies and ideally be inherited from the catalog to prevent duplication and drift. section 9.2.1 section 4.3.3
Apply row-level security across the access paths that expose governed datasets:
- Configure query engines such as Trino or Dremio to enforce row- and column-level policies before BI tools receive results. section 9.5.2
- Expose filtered data through embedded dashboards and APIs so each merchant, customer, or application receives only its authorized records. section 9.5.3 section 9.2.4
- Pair filtering with authentication, authorization, audit logging, semantic consistency, and workload controls rather than treating it as an isolated query feature. section 9.2.1
Two deployment patterns
A global bank uses a semantic layer with Tableau, Power BI, and Excel while Trino or Dremio enforces row-level security and auditability centrally. An e-commerce platform applies row-level security to embedded Metabase dashboards so each merchant sees only its own data. section 9.5.2 section 9.5.3
