Lovable prompt to set up a Postgres database schema
Screens are cheap to regenerate, schemas are not, so it pays to make Lovable commit to migrations, constraints, and RLS before any UI exists. This prompt produces a Postgres schema with enums, triggers, indexes matched to the main list query, and proof that one user cannot read another user's rows.
Last updated
Design and apply the Supabase Postgres schema for a {{resource}} app before building any screens, and show me the SQL as migration files rather than ad hoc table edits.
Tables: profiles keyed to auth.users, a {{resource}} table with owner_id, name, status, and timestamps, a comments table referencing it with cascade delete, and a join table for tags with a composite primary key.
Types and constraints: a Postgres enum for status instead of free text, not-null on every foreign key, a check constraint keeping name non-empty, and unique constraints wherever duplicates would corrupt meaning, one tag name per user for example.
Defaults and triggers: created_at defaulting to now, an updated_at column maintained by a trigger, and a trigger creating the profiles row when a user signs up.
Indexes: btree on every foreign key column, plus a composite index matching the main list query, owner_id with status and created_at descending.
Row level security: enabled on every table with select, insert, update, and delete policies written against auth.uid(), and nothing that depends on the service role.
Seed: a script inserting two demo users' worth of data so future screens have something to render.
Acceptance: the migrations run from scratch without errors, show me a query listing all tables with RLS enabled, demonstrate that user one cannot select user two's rows, and confirm the updated_at trigger fires on an update. List every migration file you created.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Design and apply the Supabase Postgres schema for a users app before building any screens, and show me the SQL as migration files rather than ad hoc table edits. Tables: profiles keyed to auth.users, a users table with owner_id, name, status, and timestamps, a comments table referencing it with cascade delete, and a join table for tags with a composite primary key. Types and constraints: a Postgres enum for status instead of free text, not-null on every foreign key, a check constraint keeping name non-empty, and unique constraints wherever duplicates would corrupt meaning, one tag name per user for example. Defaults and triggers: created_at defaulting to now, an updated_at column maintained by a trigger, and a trigger creating the profiles row when a user signs up. Indexes: btree on every foreign key column, plus a composite index matching the main list query, owner_id with status and created_at descending. Row level security: enabled on every table with select, insert, update, and delete policies written against auth.uid(), and nothing that depends on the service role. Seed: a script inserting two demo users' worth of data so future screens have something to render. Acceptance: the migrations run from scratch without errors, show me a query listing all tables with RLS enabled, demonstrate that user one cannot select user two's rows, and confirm the updated_at trigger fires on an update. List every migration file you created.
Same task in other tools
Questions about this prompt
Will Lovable use migrations instead of editing tables directly?
It applies SQL through its Supabase integration and shows you the statements for review when you ask for migration files, which this prompt does. If schema changes appear with no SQL shown, ask for the statements before approving more work.
Can I run this against an existing Supabase project with tables?
Yes. Connect the project first and tell Lovable which tables already exist so it writes additive migrations. Ask it to read the current schema rather than assuming a blank database.
The updated_at column never changes on updates. What went wrong?
Column defaults only fire on insert, so the trigger was likely skipped or created before its function. Have Lovable show the trigger definition, then run an update and confirm the fresh timestamp.