{
  "id": 16767659,
  "title": "GRANT ALL to anon is the wrong fix for Supabase 42501 after Oct 30",
  "url": "https://urgent.news/2026/10/27/grant-all-to-anon-is-the-wrong-fix-for-supabase-42501-after-oct-30",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-27T16:48:51.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/patchandship/grant-all-to-anon-is-the-wrong-fix-for-supabase-42501-after-oct-30-1bdm"
  },
  "original_language": "en",
  "account": "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.\n\nThe 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.\n\nFirst, 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.\n\nLastly, 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.",
  "summary": "From Oct 30, 2026, Supabase will apply a change to existing projects: new tables in public won't be visible to the Data API until you grant access. Supabase's changelog puts it like this: \"Once the change is rolled out to your project, new tables you create in public schema require an explicit opt-in (via a Postgres grant ) before the Data API can see them. Existing tables are not affected in…",
  "key_points": [
    "Supabase changed on Oct 30, 2026, to restrict public schema tables without explicit grant.",
    "Granting all privileges to anon role is incorrect fix due to unnecessary privileges for visitors.",
    "Enable RLS, grant specific verbs per table, and review older tables' grants for alignment."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}