Row-Level Multi-Tenant Isolation in Supabase: How We Guaranteed Zero Data Leakage

Most multi-tenant bugs aren't exploits — they're a missing WHERE tenant_id = ? clause in one query out of hundreds. In application code, that's a single line away from a data leak. The fix isn't writing more careful application code; it's moving the guarantee down into the database itself.

Why Postgres Row-Level Security

Supabase runs on Postgres, which means Row-Level Security (RLS) policies are available at the database layer. Instead of trusting every query in the codebase to filter by tenant, we wrote RLS policies that make it structurally impossible to read or write a row belonging to a different tenant — even if an application bug forgot the filter.

This is the difference between 'we tested that tenants can't see each other's data' and 'the database will not return that row no matter what query runs.' The second one survives future engineers who don't know the codebase's conventions.

The AI pipeline complication

The platform also ran an AI document pipeline, and not every document was clean, extractable text — a meaningful share were scanned images or badly-formatted PDFs. Native text extraction failed silently on those, so we added an OCR fallback: if text extraction returns near-empty content, the pipeline routes the document through OCR before it ever reaches the AI model.

Takeaway

If you're building multi-tenant SaaS on Postgres, RLS should not be optional hardening you add later — it's the guarantee your architecture is actually making. Application-layer filtering is a UX detail on top of it, not a substitute for it.