supabase

Create RLS policies using the TO clause with an ownership predicate, such as TO authenticated USING ((select auth.uid()) = user_id). Avoid the deprecated auth.role() function, and for UPDATE policies include both USING and WITH CHECK clauses.

Newly created tables may not be automatically exposed depending on your Data API settings. Grant access explicitly to the anon and authenticated roles via GRANT SQL, and always enable RLS when granting public access.

The table likely lacks explicit grants for the anon or authenticated roles, or your project's Data API settings do not auto-expose new tables. Check the dashboard settings and run GRANT statements, then confirm RLS is enabled.

No, raw_user_meta_data is user-editable and unsafe for authorization decisions in RLS policies or JWT claims. Store authorization data in raw_app_meta_data (app_metadata) instead, which users cannot modify.

In Postgres RLS, an UPDATE requires a SELECT policy first because the row must be readable before modification. Without a SELECT policy, updates silently return 0 rows with no error.

No, SECURITY DEFINER functions run with creator privileges and bypass RLS, silently removing access control. Prefer SECURITY INVOKER, and if SECURITY DEFINER is genuinely needed, keep the function in a non-exposed schema with an auth.uid() check.