Row-Level Security
also called RLS, Fine-Grained Access Control
Access control enforced by the data platform on which rows a given principal can see, rather than by each application or query.
The alternative — every query including the correct filter — is a control that depends on every developer, every analyst and every ad hoc notebook getting it right every time. It fails eventually, and the failure is a cross-tenant or cross-region data exposure that is discovered late.
Enforcing at the platform means the policy is attached to the table and applied regardless of how it is accessed: BI tool, notebook, API, direct SQL. The policy typically maps user attributes — region, business unit, tenant, clearance — to a predicate evaluated per query.
Two design cautions that matter in practice. Performance: a policy that cannot be pushed into partition pruning turns every query into a full scan with a filter, and the cost of that is not visible until the table is large. Aligning the security predicate with the physical partitioning is what keeps it affordable.
And inference through aggregates: row-level security stops a user seeing individual rows, and does not by itself stop them inferring one from a count over a group of two. Where that matters — health, HR, small-population analytics — aggregate suppression thresholds are needed as well.
The related control, column-level security and masking, handles the orthogonal case where a user may see the row but not the sensitive field within it.