What is row-level security?

What is row-level security? | Databricks Blog Skip to main content

Summary

Row-level security filters table data by user identity, role or session context, ensuring each person sees only the rows they are authorized to access across dashboards, notebooks, APIs and other tools.

Effective RLS depends on clear access logic, reliable keying columns and separate controls for read and write actions, supported by testing across multiple user roles.

RLS is most effective as part of layered governance alongside table permissions, column-level security, data masking and audit logging, since it does not protect sensitive columns or aggregate results on its own.

Row-level security (RLS) is a database access control that limits which rows of a table a user can read or change based on their identity, role or session context. Instead of restricting access to whole tables or specific columns, RLS filters data row by row. The database engine applies the filter automatically at query time, so the same rule holds no matter which tool the user uses to access the data. RLS is part of fine-grained access control, alongside: Column-level security Data masking Table-level grants

For example, a salesperson may query the company’s orders table but only see orders for their assigned region, even though the table contains every region’s data. The user writes a normal SELECT statement, and the engine returns only the rows they’re allowed to see. RLS is now a core building block for multi-tenant SaaS, regional data segregation and compliance use cases. This article covers how RLS works, where it helps, where it falls short and how it works on the Databricks Platform. How does row-level security work? Row-level security works by applying a filter rule, often called a policy or predicate, to a table. When a user runs a query, the database engine automatically applies that filter and returns only the rows the user is allowed to see. In practice, RLS usually works in three steps: The user runs a query: The user writes a standard query without adding any security filters themselves. The database checks the user’s identity: The engine evaluates the user through a built-in function like CURRENT_USER , a session variable set by the application or a mapping table that connects users and groups to permitted data. The engine filters the result: The RLS predicate returns TRUE for rows the user can see and FALSE for everything else. Only rows that pass the predicate are returned.

Because enforcement happens at the database layer, the same rule applies consistently across every access path, including BI dashboards, notebooks, ad-hoc SQL, APIs and third-party tools. That consistency is what makes RLS powerful: one rule, applied everywhere, enforced by the engine. Most engines also distinguish between read-side and write-side enforcement. A read predicate controls what a SELECT query returns. A write predicate, often defined separately with a WITH CHECK clause, controls which rows a user can insert, update or delete. The two predicates can be the same, but they do not have to be. For example, a user might be allowed to read rows for every region but only insert rows for their own region. Defining both sides matters when a table accepts writes, because skipping the write check is one of the most common ways teams misconfigure RLS in production. Row-level security vs. column-level security and other access controls RLS is one of several fine-grained access controls, and in production it’s almost always paired with others. The table below shows how each control fits. Control What it restricts Typical use case Row-level security (RLS) Specific rows in a table Limit users to their region, tenant or department Column-level security (CLS) Specific columns in a table Hide salary, SSN or PII columns from analysts Object-level security (OLS) Entire tables, views or measures Block access to a sensitive dataset altogether Data masking Visible values within a column Show only the last 4 digits of a card number GRANT / REVOKE Table-level read/write permissions Allow or deny access to the table as a whole

These controls are designed to layer. A typical setup uses table-level grants to control who can access a table, RLS to scope which rows are visible, and column-level security or data masking to protect sensitive fields within those rows. Treating them as a stack rather than a menu of alternatives makes governance both auditable and resilient. A misconfiguration in one layer doesn't compromise the others. Common use cases for row-level security RLS is the standard way to enforce who can see what inside a shared table, filtering rows based on a user's attributes against a keying column like region, tenant, or classification. Most teams reach for it when one dataset has to serve multiple audiences with different visibility rules. Multi-tenant SaaS: Isolate each customer’s data inside shared tables using a tenant_id column and session context. This avoids the operational cost of one schema or one database per tenant while keeping each customer’s data fully separated at query time. Regional segregation: Restrict sales, HR or order data so users only see records for their country or region, without splitting the underlying table by geography. Departmental access: Give finance, marketing and operations teams access to the same table but different rows, mapped by a department or cost-center column. Regulatory compliance: Enforce data residency rules, for example keeping EU records visible only to EU-based staff under GDPR, or restricting protected categories under HIPAA, CCPA or industry-specific regulations. Healthcare and clinical data: Let clinicians share a patient table while seeing only their own patients, supporting HIPAA minimum-necessary access without duplicating records across silos. Partner and vendor portals: Share a single dataset across external partners while filtering each to their own records, so one source-of-truth table can power dozens of partner-facing views.

How to implement row-level security: 4 steps The general pattern is consistent across platforms, with vendor-specific syntax filled in where needed. Identify the filter logic: Decide what determines access: user ID, group membership, region, tenant ID or a mapping table. The filter logic should be derivable from session context or a stable lookup, not from values the user controls at query time. Add or confirm the keying column: Make sure the...