Supabase Integration Rules for Zed

# Supabase Integration Rules for Zed

# Supabase Integration Rules

## Security — Row Level Security is Mandatory
- RLS enabled on EVERY table before it goes to production
- Test RLS policies with actual user sessions, not service role
- Service role key: server-side only — never in browser code
- Anon key: safe for client — but RLS is what actually protects data

```sql
-- RLS policy pattern for user-owned resources
CREATE POLICY "Users can only access own data"
ON public.notes
FOR ALL
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);
```

## Auth
- Use `@supabase/ssr` for Next.js App Router — not the legacy `@supabase/auth-helpers`
- Refresh sessions in middleware — don't let tokens expire mid-session
- `getUser()` for server-side auth check — `getSession()` is not secure server-side
- Store additional user data in `public.profiles` table with RLS, not in auth.users

## Database
- Use `supabase/migrations` folder with `supabase db diff` to generate migrations
- Never modify migration files after applying — create new ones
- `supabase gen types typescript --local` for type-safe queries
- Indexes on: foreign keys, frequently filtered columns, search columns

## Realtime
- Enable realtime per-table only for tables that need it — not globally
- Use `postgres_changes` for data sync — efficient and secure
- Filter subscriptions: `filter: `user_id=eq.${userId}`` — don't stream all changes
- Presence channel for cursor sharing, online status — not for data sync

## Storage
- RLS on storage buckets — same pattern as tables
- Signed URLs for private files (1-hour expiry typical)