The login succeeded, but the query returned nothing. You check the database. The rows are there. The problem is access. The problem is identity management with row-level security.
Row-Level Security (RLS) is not a feature to turn on and forget. It is a guard that decides what data a specific identity can read, update, or delete. Identity management is the system that proves who you are. Together, they form a gate where rules are enforced at the deepest layer — inside the database itself.
Without RLS tied to strong identity management, you risk leaking confidential rows to the wrong user or service. Application-layer checks can fail. SQL injection, misconfigured APIs, and broken caching layers can bypass weak filters. RLS ensures the condition is enforced even if your application has a flaw.
To implement RLS with identity management, bind the database session to an authenticated identity. Pass a user ID, tenant ID, or role claim into the session context at connect time. Define policies at the table level that match row attributes against this session context. For example: policy for select using (tenant_id = current_setting('app.tenant_id')::uuid) in PostgreSQL. This design ensures the database itself refuses any row outside the user’s scope.
Performance matters. Badly written RLS policies can trigger full table scans. Optimize by indexing the columns used in policy conditions and by minimizing casts or functions inside those conditions. Keep policies simple and let the database handle the filtering at index level.