Row-Level Security (RLS)

Row-level security (RLS) is a database feature that restricts which rows a given user or session can see or modify, enforced inside the database engine itself. Instead of relying on application code to add the right WHERE clause on every query, the administrator defines policies on a table — for example, that a row is visible only when its tenant_id matches the tenant of the current session. The database then applies that filter automatically to every read and write, so a query that forgets the filter simply returns nothing rather than leaking other rows.

RLS is a primary defense for data isolation in multi-tenant SaaS, where many customers' records share the same tables. Its value is that it is enforced at the lowest layer: even a bug in the application, a malformed query, or a compromised code path cannot return rows the policy forbids. This is a meaningful upgrade over application-only filtering, which is correct only as long as every query is written correctly — an assumption that fails as a codebase grows.

Implementations typically pair RLS with a controlled way to set the session's identity, such as running tenant-scoped requests inside a context that stamps the current tenant, plus a separate, deliberately privileged path for trusted system operations that must cross tenants (like billing webhooks). Getting RLS right means every table holding tenant or personal data has a policy and no table is silently left open, which is why teams audit for tables where RLS is disabled.