Supabase RLS and auth patterns we use in 2026

Supabase accelerated dozens of ADSA Labs prototypes: auth, Postgres, storage, and realtime in one stack. The foot-gun is treating the anon key like a backend secret or disabling RLS because 'we'll filter in the API later.'

Our default: RLS enabled on every table with tenant or user scope; policies named and reviewed in migration files under `supabase/migrations`. Server actions and Route Handlers use the service role only when bypassing RLS is intentional — admin exports, webhooks, batch jobs — and those code paths get extra logging.

For Next.js SSR we use `@supabase/ssr` cookie patterns so sessions refresh without exposing long-lived tokens to client storage tricks. Finance and admin modules never trust client-supplied user IDs; the session is verified server-side on every mutation.

When Postgres is paused or REST times out, the site should degrade gracefully. Public pages do not call Supabase at build time; admin shows a clear error instead of hanging. Operational maturity matters as much as policy SQL.