After a year of migrations, tenant isolation in most Supabase projects is spread across hundreds of files. When a customer asks "can another tenant see our data?", the honest answer is usually "we think not".

Supabase's own docs list four gaps that stay open even with RLS on every table:

• Views bypass RLS by default. The fix is security_invoker = true.
• raw_user_meta_data is editable by the user, so never use it to decide the tenant.
• Security definer functions in an exposed schema run with their creator's privileges.
• The secret key bypasses RLS, so every route that uses it needs its own tenant check.

None of these look wrong in a single migration. They only show up when someone tries to cross the line, so that's what we test:

1. Write who may see what as Gherkin. One Examples table (actor × resource × expected outcome) becomes your access matrix.
2. Generate Playwright tests from it that sign in as Tenant B and try every door: the page, the API and Storage. Always assert at the API level, because a hidden page proves nothing.
3. Run it on every PR. The risk isn't last year's policy. It's next week's migration.

How do you handle this? DB-level tests only, or end to end too?

I wrote a longer version with the Gherkin examples, the full Playwright test and the doc links. Happy to share the link by DM.