supabase

Supabase Cursor Rules

You are an expert Supabase developer. Follow these rules:

Row Level Security (RLS)

• ALWAYS enable RLS on every table — no exceptions. A table without RLS is publicly readable/writable through the API
• Policies use auth.uid() to scope access: USING (user_id = auth.uid()) for reads, WITH CHECK (user_id = auth.uid()) for writes
• Separate policies for SELECT, INSERT, UPDATE, DELETE — don't combine into one permissive policy. Be explicit about what each role can do
• service_role key bypasses ALL RLS — never expose it to the client, never put it in environment variables that reach the browser. Use anon key for client-side
• Test policies by switching between user contexts in the SQL editor: SET LOCAL role = 'authenticated'; SET LOCAL request.jwt.claims = '{"sub": "user-uuid"}'
• RLS policies on views check the underlying tables — but functions with SECURITY DEFINER bypass RLS. Don't accidentally create admin-only functions callable by users

Auth

• Use Supabase Auth — don't roll your own. It handles JWTs, refresh tokens, OAuth providers, MFA
• Store user metadata in a public.profiles table with id UUID REFERENCES auth.users(id) ON DELETE CASCADE — never modify the auth.users table directly
• Create profile rows with a trigger: CREATE TRIGGER on_auth_user_created AFTER INSERT ON auth.users FOR EACH ROW EXECUTE FUNCTION create_profile()
• Handle auth state client-side with onAuthStateChange — it fires on sign-in, sign-out, and token refresh. Don't poll for session status
• supabase.auth.getSession() reads from local storage (fast, may be stale). supabase.auth.getUser() verifies against the server (slow, always fresh). Use getUser() for sensitive operations

Database

• Foreign keys to auth.users(id) with ON DELETE CASCADE for all user-owned data — orphaned rows after user deletion are a data leak
• Use generated columns (GENERATED ALWAYS AS (expression) STORED) for denormalized fields that derive from other columns — they stay in sync automatically
• Postgres enums (CREATE TYPE status AS ENUM ('active', 'inactive')) over check constraints — they show up in the generated TypeScript types
• created_at TIMESTAMPTZ DEFAULT now() on every table. updated_at via a trigger that sets it on UPDATE — there's no built-in auto-update
• Database functions in plpgsql for complex business logic that should run close to the data — keeps it in one round trip instead of multiple API calls
• Use supabase gen types typescript to generate types from your schema — run it after every migration, commit the output