Larik

Ah, my mix-up — the "boost" was meant for Colin's comment, I threaded it wrong. Thanks for the fair take. If the grant/policy edge cases ever bite you, I'm around here.

No, different person and different tool — I don't know Perufitlife. Mine is supabase-grants (github.com/larik15), focused on the grant vs policy mismatch specifically. Happy to answer anything technical here so you can judge it on the code, not on me.

Thanks Colin — fair point on the noise above, and thanks for the boost. If anyone hits an edge case (views, sequences, functions, or multi-schema setups), happy to help work through it here.

@jackswisher that parse error most likely means the branch builder runs a CLI version older than v2.102.0, which doesn't know the `auto_expose_new_tables` key. Workaround until branches catch up: remove the key from `config.toml` and put the revoke block at the top of your first migration (what @matepek posted above). The key is scheduled for removal on Oct 30 anyway, so the migration-based version is the one that lasts. @colinemondswieprecht this is the case I'd worry about most. A fresh deploy replays migrations written when grants were implicit, so every table comes up unreachable. The fix is one catch-up migration placed *last* in the chain (it has to run after every `create table`): ```sql grant select, insert, update, delete on all tables in schema public to authenticated, service_role; grant usage, select on all sequences in schema public to authenticated, service_role; grant execute on all functions in schema public to authenticated, service_role; -- then anon only where you actually need it, per table: grant select on public.some_public_table to anon; ``` Two things to check before shipping it: - `on all tables` also re-exposes tables you meant to keep private (queues, audit logs). Revoke those right after. - Views count as tables here. If a view is granted to anon/authenticated, create it `with (security_invoker = on)`, otherwise it bypasses the RLS of the underlying tables. After that, add the grant in the same migration as every new table. Test with `supabase db reset` against a project that has the new default. That's the only run that proves the chain rebuilds without the implicit grants.