The database never lies, but it can still betray you if the wrong eyes see the wrong rows. Lean Row-Level Security (RLS) is how you stop that.
Row-Level Security controls which rows a query can return for a given user, role, or context. Without it, you’re left writing ad-hoc filters in every API endpoint. That breeds complexity, bugs, and hidden attack surfaces. Lean RLS strips the concept down to its smallest, cleanest form—security policies at the database level with no excess layers.
In Lean RLS, filtering is enforced by the database engine itself. PostgreSQL, for example, lets you define CREATE POLICY rules on tables. Those rules decide which rows a user can SELECT, INSERT, UPDATE, or DELETE. Unlike application-level checks, these policies apply to every query, whether it comes through the app, a script, or direct database access.
The “lean” part is about scope and clarity. Keep policies minimal: one table, one policy per operation type, written in SQL that reads like a statement of fact. No nested functions. No hidden joins. This makes auditing possible with a glance and reduces the risk of permission drift over time.
For example, a lean RLS setup in PostgreSQL might look like this: