Supabase Ecosystem
Supabase is the Postgres-backed product stack route for database, auth, storage, realtime, and RLS work where the app wants SQL ownership without hand-building the entire backend platform. Source: Ecosystem Capability Coverage, 2026-06-27; Skill Resolver, 2026-06-27
When To Use This
Use Supabase when a task names Supabase, Postgres migrations, RLS, auth tables, generated database types, storage policies, or database-local development. Use generic database guidance only after the Supabase route is accounted for. Source: Skill Resolver, 2026-06-27
Decision Matrix
| Need | Route | Verification |
|---|---|---|
| Inspect project/schema | Supabase MCP, read-only | Schema and policy readback |
| Create migration | supabase CLI |
supabase db diff, migration review |
| Review RLS/Postgres | Frontend and Design Skills | Policy tests or query checks |
| App integration | Security and Review Skills skill | Type generation and local smoke |
Core Model
Supabase is not just a database page. It spans Postgres schema, RLS policy, auth identity, storage permissions, and generated client types. Treat the schema and policies as production code. Source: Frontend and Design Skills, 2026-06-27
Auth Performance Boundary
For normal application paths that need JWT claims, prefer supabase.auth.getClaims() over supabase.auth.getUser() when the project uses asymmetric JWT signing. Supabase's JavaScript docs say getClaims() verifies the access token against the JWKS endpoint, which is often cached, while getUser() always sends a request to the Auth server. If the project uses symmetric JWT signing, getClaims() falls back to a server request similar to getUser(). Source: Supabase getClaims docs, 2026-07-04; Source: Supabase getUser docs, 2026-07-04
This is a latency and DB-load rule, not an authorization shortcut. For sensitive actions, keep the existing security rule: JWT claims can be stale until token refresh, user_metadata is user-editable, and server-side state may still need validation. Source: Supabase Auth bookmark and local image review, 2026-07-04
Routing Summary
Preferred order: Supabase MCP for read-only inspection, supabase CLI for local/project/migration operations, then Security and Review Skills and Frontend and Design Skills for procedural review. Source: Skill Resolver, 2026-06-27
Failure Modes
- Writing tables before defining the access model.
- Treating RLS as a patch after app code works.
- Mutating a remote project without confirming project ref and environment.
- Shipping client queries without generated types or policy proof.
Verification Path
Use supabase status, supabase db diff, supabase migration list, and type generation where available. For policy work, prove allowed and denied paths with tests or explicit SQL checks. Source: config/capability-harvest-seeds.json; Skill Resolver, 2026-06-27
Timeline
- 2026-07-04 | Added the
getClaims()vsgetUser()Auth performance boundary.getClaims()can avoid repeated Auth-server requests through cached JWKS verification on asymmetric signing keys; sensitive authorization still requires freshness/server-state checks. Source: Supabase docs and X/@supabase, 2026-07-04 - 2026-06-27 | Canonical ecosystem page created to unify Supabase CLI, MCP, skills, RLS guidance, and database pack placement. Source: User request, 2026-06-27; Ecosystem Capability Coverage