Database column references exist in schema

A hallucinated column name is subtler than a hallucinated table name and more dangerous in Supabase projects: Prisma's TypeScript client will flag unknown field names at compile time if types are regenerated, but Supabase's PostgREST API silently ignores an unrecognized column in .select() — returning a result set with the column omitted and no error. An unrecognized column in .eq('avatarUrl', ...) makes the filter a no-op, so the query returns all rows instead of the intended subset. This is an OWASP A08 data-integrity failure that can expose records to the wrong user if the broken filter was access-gating data.

Match every column reference exactly to the column name in the schema. SQL column names are case-sensitive in comparisons and typically snake_case; AI-generated code frequently uses camelCase by habit.

// Prisma
await prisma.user.findMany({ where: { emailAddress: 'a@b.com' } })  // Bad
await prisma.user.findMany({ where: { email: 'a@b.com' } })          // Good

// Supabase — wrong casing makes the filter a silent no-op
await supabase.from('profiles').select('avatarUrl')   // Bad
await supabase.from('profiles').select('avatar_url')  // Good

await supabase.from('profiles').eq('displayName', 'Alice')   // Bad: filter ignored
await supabase.from('profiles').eq('display_name', 'Alice')  // Good

For Supabase projects, generate TypeScript types with supabase gen types typescript and pass them to the client constructor — column name typos then fail at compile time rather than silently at runtime.