Technologies
Supabase Database Development
Supabase's database is just PostgreSQL, which means standard schema design principles — normalization, foreign keys, indexes — apply directly, on top of Supabase's own layer of auto-generated APIs, row-level security, and realtime subscriptions.
I design schemas around the actual relationships in the data first, then layer RLS policies and API access on top, rather than starting from Supabase's tooling and working backward.
What Goes Into a Schema
- checkTables and relationships modeled around the real data, not a generic template
- checkForeign keys and constraints enforced at the database level
- checkIndexes on columns used in frequent queries and filters
- checkRow-level security policies scoping access per user or organization
- checkDatabase functions and triggers for logic that belongs at the data layer
Migrations
Schema changes go through versioned migration files rather than manual edits in the Supabase dashboard, so changes are tracked, reviewable, and reproducible across environments — the same discipline as any standard Postgres migration workflow.
Frequently Asked Questions
Can I use raw SQL with Supabase?add
Yes — since it's standard PostgreSQL, you can write raw SQL migrations, functions, and triggers alongside using Supabase's auto-generated client APIs for typical queries.
How does Supabase's auto-generated API work?add
It exposes a REST and GraphQL-compatible API directly from your Postgres schema, so CRUD operations don't require writing a separate backend layer — though row-level security is what actually governs what each request is allowed to do.
Can I migrate away from Supabase later if needed?add
The database itself is portable since it's standard Postgres — the main migration work if you moved away would be replacing Supabase's auth and auto-generated API layer with your own equivalents.