supabase-core

name	supabase-core
description	Shared reference for the Supabase cluster: the authorization model (Row-Level Security as the one boundary every product enforces), the keys/roles that reach the database, the auth-claims rule (app_metadata not user_metadata), the security-checklist traps, and the schema-change → advisor → migration workflow. USE WHEN designing tables, writing RLS policies, choosing keys, reviewing security, or shipping a Supabase schema change — the interlocking rules every Supabase spoke shares.
cluster	supabase
version	1.0.0

Supabase Core

Shared model for the supabase cluster. The feature-build, current-API, and performance spokes all depend on these interlocking concepts — keep them consistent here so no spoke contradicts another.

1. The authorization model (Supabase's defining decision)

Authorization lives in the database, as Postgres Row-Level Security. Supabase exposes your tables directly (the auto-generated Data API / PostgREST), so a request can reach a table without passing through any app server. RLS is the boundary every product enforces:

Request ──carries──> Role + JWT claims ──checked by──> RLS Policy(ies) ──on──> Table/Storage object

• RLS is default-deny once enabled, but OFF by default on a new table. Enable RLS on every table in an exposed schema (especially public), then write policies that match the actual access model — don't reflexively stamp the same policy on every table. → ,