Error fixes / Supabase
Supabase
Supabase: permission denied for table
The database role behind the API key does not have a GRANT to use that table.
The error
permission denied for table profiles
What it means
This is a privilege error, not a policy error. Postgres error 42501 means the role (often anon or authenticated) has not been granted the action. RLS policies do not matter until the GRANT exists. Generated SQL sometimes creates a table in public and forgets the grants Supabase usually adds for API access.
Fix
- Read the table name in the error. In the SQL editor, check privileges for anon and authenticated.
- Grant only what the API should do. A typical pattern is GRANT SELECT, INSERT, UPDATE, DELETE on that table to authenticated, and a narrower grant to anon if signed-out users really need it.
- Turn RLS on as well. A GRANT without RLS exposes every row to that role.
- If the table is not meant to be public, do not grant anything to anon. Call it from a server route that uses a checked session.
- Retry the request as the same role the app uses. A success in the SQL editor does not prove the grant.
Prompt
Fix prompt
The API returns: permission denied for table profiles. Replace profiles with the table in the real error. Do not grant ALL to anon. In a migration, GRANT the minimum actions to authenticated (and anon only if signed-out access is intended). Then ENABLE ROW LEVEL SECURITY and add policies so users only touch their own rows. Show me the SQL. Do not print keys or connection strings.
Questions
How is this different from a row-level security error?
Permission denied means the role has no GRANT. A row-level security error means the role can reach the table, but no policy allows that specific row. You may need to fix both.
Can I grant access to the service role instead?
The service role already bypasses RLS. Using it from the browser to get past this error exposes the whole database. Keep that key on the server.
I granted SELECT and I still cannot insert. Why?
SELECT and INSERT are separate privileges. Grant each action the app actually performs, then add a matching RLS policy for that action.