Why We Use Row-Level Security — and Why It Matters for Your Clients

Most platforms enforce data isolation in application code. We enforce it in the database itself. Here is why that distinction matters.

There are two places you can enforce 'only show this practitioner their own clients': in the application code, or in the database itself. Most platforms choose the application layer because it is easier to build. We chose the database.

PostgreSQL's row-level security (RLS) lets us attach policies directly to tables. A policy on the clients table says: 'this row is only visible to the practitioner whose ID matches the practitioner_id column.' Even if there is a bug in our API that accidentally sends a query without a filter, the database simply returns nothing.

This is not just theoretical protection. Application-layer isolation has caused real data breaches at real companies — a misconfigured cache, a missing WHERE clause, a rushed feature deployment. With RLS, those bugs cannot leak cross-tenant data because the database enforces the boundary regardless.

The implementation uses Supabase's auth.jwt() function, which reads the practitioner_id claim baked into your session token. No extra database round-trips, no race conditions.