Row-Level Security (RLS)

In a multi-tenant application, every table holds data for many customers, and the cardinal rule is that one tenant must never see another's rows. The naive approach filters in application code with a WHERE clause on every query — but a single forgotten filter becomes a data breach. RLS moves that guarantee down into the database, where policies are attached to tables and applied automatically to every statement.

An RLS policy is a rule the database evaluates per row: it can read session context (such as the current tenant or user identifier) and decide whether a given row is visible or writable. Because it runs inside the database engine, it covers every code path — ORMs, raw SQL, migrations, and ad-hoc queries alike — closing the gap that pure application-layer checks leave open.

RLS is defense in depth, not a replacement for application authorization; the two layers reinforce each other. The cost is care in setting session context correctly and in reasoning about policy performance, since policies execute on every row touched.

Planoda enforces tenant isolation with PostgreSQL row-level security policies applied at the database layer, so workspace boundaries hold even if application code is wrong.