Row-Level Security in PostgreSQL: The Last Line of Defense for Multi-Tenant SaaS

The most common multi-tenant data isolation pattern in SaaS is application-layer enforcement: every query includes a WHERE org_id = ? clause, and the application code is responsible for ensuring the right org_id is always passed. This works until it does not.

Application code has bugs. New engineers forget the WHERE clause. A refactor introduces a query path that bypasses the check. An ORM generates a query without the expected filter. These are not hypothetical scenarios — they are the root cause of most multi-tenant data leaks.

What RLS Actually Does

Row-Level Security is a PostgreSQL feature that attaches access policies to tables. When enabled, every query against the table — regardless of where it comes from — is filtered by the policy. The database engine enforces the policy before returning results. It cannot be bypassed by application code.

-- Enable RLS on the table
ALTER TABLE api_requests ENABLE ROW LEVEL SECURITY;

-- Create policy: users can only see their own org's rows
CREATE POLICY org_isolation ON api_requests
  USING (org_id = current_setting('app.current_org_id')::uuid);

-- Set the org context at the start of each request
SET LOCAL app.current_org_id = '550e8400-e29b-41d4-a716-446655440000';

-- Now this query automatically filters to the current org
SELECT * FROM api_requests WHERE created_at > NOW() - INTERVAL '1 day';

G8KEPR's Implementation

G8KEPR enforces tenant isolation at the database layer using RLS on all tables containing customer data. The org context is set at the start of every request handler by the authentication middleware. If a bug in application code issues a query without the expected filter, the database returns an empty result set rather than another tenant's data.

This has come up in pentest. During Red Team Run 2, the testers found an authentication path that briefly exposed a non-tenant-scoped query. The RLS policy meant the query returned zero rows — no data was exposed. Without RLS, that finding would have been Critical.

Trade-offs

RLS adds overhead to every query. In our benchmarks, the overhead is 2-5% per query on tables with RLS enabled — acceptable for the security guarantee. Queries against non-RLS tables (e.g., lookup tables, public data) are unaffected.