GRANT ALL to anon is the wrong fix for Supabase 42501 after Oct 30

On October 30, 2026, Supabase implemented a change affecting existing projects: new tables in the public schema will no longer be visible to the Data API until an explicit grant is provided. Existing tables are unaffected and retain their current grants. When the change is implemented, the first new table added will likely result in a 42501 permission denied error. The common quick fix suggested by AI assistants, granting all privileges to the anon role, is not the correct solution.

The 42501 error can occur due to three reasons: no grant, a grant exists but RLS is hiding rows, or a violation of the row-level security policy. A broad grant does not resolve the other two issues. Granting all privileges to the anon role is incorrect because the anon role represents the public key in every browser loading the app, and most privileges are unnecessary for signed-out visitors.

First, enable Row-Level Security (RLS) on all tables before granting any privileges. With RLS enabled and no policies, the table returns no data to API roles, providing a safe starting point. Then, grant only the specific verbs each table requires. For a typical per-user table, signed-in users need SELECT, INSERT, and UPDATE privileges, while signed-out visitors only need SELECT.

Create policies to enforce these privileges. For a table intended to be public, such as a published product list, grant SELECT to the anon role and create a policy limiting visibility to published products.

Lastly, review older tables to ensure their grants align with the new requirements. Use two queries: one to check what anon and authenticated roles can do on each table, and another to identify tables with RLS disabled and grants for anon or authenticated roles. Only revoke grants if necessary, ensuring public pages remain functional.