"Grant the required privileges to the current role with: GRANT ..."

Reading the hint

GRANT SELECT ON public.your_table TO anon;

Why running the hint alone is rarely enough

• It covers one privilege. Reads work, then the first save fails with a new hint for INSERT.
• It covers one role. Signed-out pages work, signed-in pages fail, or the other way round.
• It says nothing about rows. A grant without row level security and policies can expose every row to that role.
• The role in the hint is the one that made the request, which may not be the one that should have access. A hint naming anon on a private table often means the user was not signed in.

The tool reads the table and role from a pasted error and proposes a full set you can adjust. It starts from the closed side: a hint that names anon starts as Private, a hint that names authenticated starts as Owner only. Public read is never preselected from a hint, and choosing it shows a warning.

If the error says "view"

permission denied for view your_view is a different case, and the tool writes no SQL for it. A view cannot have row level security of its own. Grant select on the view to the role that reads it, create the view with security_invoker = true (Postgres 15 and later) so the policies of its base tables apply, and fix the grants and policies on those base tables.

Sources

• Supabase changelog: Breaking Change: Tables not exposed to Data and GraphQL API automatically (published 2026-04-28), read 2026-11-10
• Supabase docs: Securing your API, read 2026-11-10
• Supabase docs: Postgres Roles, read 2026-11-10
• Supabase docs: Row Level Security, read 2026-11-10