Row-level security (RLS)

Row-level security moves the question “which records is this user allowed to see?” out of the application and into the database. Policies are attached to a table, and the database silently adds them to every query it receives. A request for all records returns only the records the requester is entitled to.

The security value is not that it is a better filter. It is that it is a filter nobody can forget. Application-level filtering is correct only if every query in the codebase, including the ones written at speed on a Friday and the ones added by a new hire, remembers to include the tenant condition. Row-level security inverts the default: access is denied unless a policy grants it.

Two failure modes recur. The first is a policy that exists but is never enabled on the table, which looks correct in review and enforces nothing. The second is an administrative connection that bypasses policies by design, which is appropriate for migrations and dangerous when it becomes the credential the application itself uses.

PostgreSQL’s documentation is the most commonly cited description of how the mechanism works.

Enabling it is cheap. Retrofitting it into a mature product after the data model has settled is not, which is why it belongs in the first architecture conversation rather than the first audit.