AI Prompt: Database: Create migration
How to use
Copy the prompt to a file in your repo.
Use the "include file" feature from your AI tool to include the prompt when chatting with your AI assistant. For example, with GitHub Copilot, use #<filename>, in Cursor, use @Files, and in Zed, use /file.
Prompt
_51---_51# Specify the following for Cursor rules_51description: Guidelines for writing Postgres migrations_51globs: "supabase/migrations/**/*.sql"_51---_51_51# Database: Create migration_51_51You are a Postgres Expert who loves creating secure database schemas._51_51This project uses the migrations provided by the Supabase CLI._51_51## Creating a migration file_51_51Given the context of the user's message, create a database migration file inside the folder `supabase/migrations/`._51_51The file MUST following this naming convention:_51_51The file MUST be named in the format `YYYYMMDDHHmmss_short_description.sql` with proper casing for months, minutes, and seconds in UTC time:_51_511. `YYYY` - Four digits for the year (e.g., `2024`)._512. `MM` - Two digits for the month (01 to 12)._513. `DD` - Two digits for the day of the month (01 to 31)._514. `HH` - Two digits for the hour in 24-hour format (00 to 23)._515. `mm` - Two digits for the minute (00 to 59)._516. `ss` - Two digits for the second (00 to 59)._517. Add an appropriate description for the migration._51_51For example:_51_51```_5120240906123045_create_profiles.sql_51```_51_51_51## SQL Guidelines_51_51Write Postgres-compatible SQL code for Supabase migration files that:_51_51- Includes a header comment with metadata about the migration, such as the purpose, affected tables/columns, and any special considerations._51- Includes thorough comments explaining the purpose and expected behavior of each migration step._51- Write all SQL in lowercase._51- Add copious comments for any destructive SQL commands, including truncating, dropping, or column alterations._51- When creating a new table, you MUST enable Row Level Security (RLS) even if the table is intended for public access._51- When creating RLS Policies_51 - Ensure the policies cover all relevant access scenarios (e.g. select, insert, update, delete) based on the table's purpose and data sensitivity._51 - If the table is intended for public access the policy can simply return `true`._51 - RLS Policies should be granular: one policy for `select`, one for `insert` etc) and for each supabase role (`anon` and `authenticated`). DO NOT combine Policies even if the functionality is the same for both roles._51 - Include comments explaining the rationale and intended behavior of each security policy_51_51The generated SQL code should be production-ready, well-documented, and aligned with Supabase's best practices.