Move RLS verification into the policy editor, not beside it

Supabase paused the RLS Tester feature preview in April while re-evaluating its direction. This is a concrete proposal for that direction, with a working prototype.

The argument in one line: the tester was the right capability in the wrong place. Verification that lives beside authoring is a destination people have to remember to visit, and the moment you most need it is the moment you don't know you need it, because a too-strict policy looks exactly like no data.

Try it: https://ishwaryasuresh.github.io/deny-by-default/

The prototype there runs a real RLS interpreter over a sample table (grants → role → permissive OR → restrictive AND), so the policy you build is genuinely evaluated rather than mocked. There's a 3½ minute narrated walkthrough if you'd rather watch than click.

The research

I pulled every discussion in this repo matching "RLS policy" (800), filtered out show-and-tell, and kept the 438 where a policy is the actual subject. Coded each on title and opening post; 27.9% resisted single-theme coding and are reported as unclassified rather than forced.

Pattern	Threads	Share
Right policy, wrong identity (auth.uid() null, anon key, third-party JWT, server-side with no session)	150	34.2%
USING vs WITH CHECK (mostly new row violates row-level security policy on INSERT)	134	30.6%
Grants, not policies (42501, reads as a policy failure and isn't)	60	13.7%
Expressing the rule at all (multi-tenant, org scoping, joins)	49	11.2%
Policy combination	47	10.7%
Silent denial, named as the problem itself	38	8.7%
No way to verify	15	3.4%
Performance	14	3.2%
Recursion	9	2.1%

The one I'd flag: silent denial reads as small at 8.7%, but it isn't a category. It's the delivery mechanism for most of the others. A wrong identity, a missing grant and a restrictive-instead-of-permissive policy all arrive identically, as an empty array and a 200.

For scale, the repo carries 1,524 discussions and 405 issues mentioning RLS. Volume hasn't declined: 2023 and 2025 are the peak years.

What the proposal is

Five components, all in the prototype:

1. Intent-first authoring. Three questions instead of a form whose every field is labelled with the SQL clause it populates. The to clause defaults to authenticated. The USING / WITH CHECK split becomes a consequence of the command rather than a question you answer, which is what #180 promised in 2020.
2. A live result panel, before save. The tester, moved inside. Real rows, real callers, updating as you type.
3. The denial explainer. When the result is empty it says which layer emptied it. This is the ask in #9214, open since 2022, delivered as an interface rather than a log line.
4. The access path view. Grants → role → permissive OR → restrictive AND, for a chosen caller, with the failing step marked.
5. Defaults that ship the recommended form.

One thing I got wrong, and corrected

My first version modelled every denial as silent. Per the docs' own table, that's wrong: a missing grant and a with check violation both raise 42501, and only a using filter is quiet. The prototype now models writes as loud and reads as silent, because conflating them overstates the problem. Reads are the silent case, and they're still a third of the corpus.

Happy to be told I've misread the direction you're re-evaluating toward.