Why should you care?

PostgresVerse SaaS tenants must never SELECT neighbor data even if API sends wrong tenant_id once.

See it live — copy this example

Run in pgAdmin or psql.

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant_id')::int);

SET app.tenant_id = '3';
SELECT order_id FROM orders;

What happened?

• Policy compares row tenant_id to session setting app.tenant_id.
• SET before query simulates app setting GUC per request.
• Other tenants rows invisible.

Practice next

1. Add tenant_id to orders and ENABLE RLS.
2. CREATE POLICY as shown.
3. SET tenant 3; count rows; SET tenant 5; compare.
4. ADD POLICY for INSERT WITH CHECK same tenant_id.
5. Combine RLS with SECURITY DEFINER function carefully audited.

Remember

RLS is database-enforced multi-tenant guard. Policies per command: SELECT, INSERT, etc. FORCE RLS applies to table owner too.

PostgresVerse tenant leak prevention

Buggy API omits tenant filter; RLS still returns only tenant 3 rows.

Outcome: Security audit passes; competitor data never exposed.