Row-level security (RLS)

Row-level security, RLS, restricts which rows of a table a given user can see when they query it, rather than granting or denying access to the table as a whole. A sales rep and a sales VP might both query the same deals table, with RLS silently filtering the VP's query to all regions and the rep's to only their own accounts.

RLS is implemented either in the database itself, most major warehouses support native row-level policies, or in a semantic layer or BI tool sitting above it. It complements role-based access control, which decides whether a user can access a table at all; RLS then decides which subset of rows they see once inside. It's a different mechanism from data masking, which alters values within visible rows rather than hiding entire rows.

RLS matters for multi-tenant products, franchise or regional businesses, and any setting where the same report needs to show different data to different viewers without maintaining separate copies. It's a common requirement under data governance policies for data segregated by customer or business unit, and usually depends on a data classification scheme to identify which tables need it. The main pitfall is defining RLS rules that don't compose cleanly: users with more than one applicable role can end up seeing unintended unions or, worse, silently see nothing when policies conflict.