Row-Level Security (RLS)
A database feature that enforces, per row, which users or tenants can read or write a record — isolation guaranteed by the database itself.
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 column 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.
Row-level security is built into several databases, among them PostgreSQL, Microsoft SQL Server and Oracle, which calls it Virtual Private Database. In PostgreSQL it is switched on table by table, and each policy is a condition checked against every row a query would read or change. When RLS is on and no policy grants access, access is denied by default; superusers and roles allowed to bypass RLS are not filtered, and neither is the table's owner unless the table is set to force row security.
Read more on the blog, or compare Kirality to the alternatives.