Supabase-first database schema design for Nick's app stack. Generate production-ready Postgres schemas, Supabase SQL migrations, RLS policies, TypeScript types, seed data, role-aware access patterns, and schema checklists from plain English requirements. Use when starting any new project database, designing or reviewing schemas, adding tables, planning migrations, or turning product requirements into Supabase-ready data models. Bias toward product-led schema design, MVP discipline, core-workflow-first modeling, and avoiding premature table/role sprawl.
Use this as the default database design skill for Nick's projects.
Turn product strategy into a schema that supports the real workflow without overbuilding the backend.
Do not optimize for theoretical completeness. Optimize for:
When available, anchor schema design to:
If these are unclear, state assumptions and keep the schema narrow.
Generate what is justified by the product stage. Usually include:
Do not force complexity just to check boxes.
Start with:
If a table does not support the core workflow, challenge whether it belongs in v1.
For v1, usually prefer:
Push out unless justified:
Include monetization-relevant records when the product needs them, such as:
Do not add monetization tables by default if the current product stage does not need them.
Separate clearly when relevant:
If the app only needs one or two roles in v1, do not invent five.
For each schema design, include:
auth.users is the source of authenticated identitycreated_at and updated_at on app tables by defaultdeleted_at only when soft delete is truly neededChallenge or remove these unless the product clearly needs them now:
When writing policies, define explicitly:
Prefer policies that are easy to reason about and test.
If policy logic becomes complicated, question whether the schema or role design is too complex for the current stage.
Seed enough data to test:
Do not generate toy seed data that fails to exercise the real product.
When designing or reviewing a schema, structure the response around:
A strong schema response should:
Read these as needed:
references/schema-workflow.md for the end-to-end processreferences/rls-patterns.md when writing access policiesreferences/table-template.md when structuring table specsreferences/common-patterns.md for auth/profile/tenant defaultsreferences/review-checklist.md before finalizing schema outputreferences/multi-role-planning.md when multiple roles actually matterreferences/migration-conventions.md when sequencing changes mattersreferences/policy-test-template.md for RLS verification structurereferences/storage-patterns.md when uploads/storage are part of the productscripts/init_schema_design.sh — create a schema design stubscripts/generate_table_spec.sh — create a table spec stubscripts/generate_migration_checklist.sh — create rollout/test checklistscripts/generate_policy_test_checklist.sh — create an RLS verification checklist for a tablescripts/generate_seed_plan.sh — create a realistic seed-data planning stubscripts/generate_storage_policy_stub.sh — create a Supabase Storage policy stub