Database Migrations taste — ChatGPT prompt: what it does
System prompt with strict guidelines for zero-downtime schema changes. Teaches AI assistants to write reliable, backward-compatible SQL migrations.
Open on GitHubWhat Database Migrations taste does
This prompt embeds disciplined engineering rules into the assistant for database schema workflows. It directs the AI to write raw SQL rather than uninspected ORM diffs, keep migrations versioned alongside application code, and treat applied migrations as immutable. Schema changes follow the expand and contract pattern so deployments never break active traffic on older app versions.
The rules include specific safeguards for heavy PostgreSQL workloads. New columns must be nullable or use constant defaults to avoid full table rewrites. Heavy index additions require CREATE INDEX CONCURRENTLY outside transactions. Every migration script starts with short lock_timeout and statement_timeout limits, while massive backfills belong in batched background workers.
Applying these guidelines to databases lacking concurrent index builds or granular timeout controls will require adjusting the raw SQL scripts manually.
What it helps with
- generate zero-downtime SQL migrations for production tables
- add PostgreSQL indexes concurrently without locking writes
- migrate column names safely using views and dual-write steps
- structure data backfills into batched background jobs
Example prompts for the agent
- Write a SQL migration to add an email column to users without table rewrites.
- Plan an expand-and-contract migration to rename the order_total column.
- Create a PostgreSQL migration for adding a foreign key with NOT VALID.
How to install Database Migrations taste
How to use
Paste the text at the start of a chat or into project instructions
Manually: put the files in place
.claude/commands/prompts.csv.mdQuestions about Database Migrations taste
How to install Database Migrations taste in ChatGPT?
Paste the prompt content into your ChatGPT Custom Instructions or directly into your chat session before asking for schema changes.
What does Database Migrations taste do?
It establishes strict guidelines for schema evolution, enforcing forward-only plain SQL, safe locks, and zero-downtime backward compatibility.
Why does the prompt advise against editing existing migrations?
Editing migrations that already ran in shared environments breaks schema tracking and deploy safety. New schema modifications must always live in a separate migration file.
Source text
prompts.csv · CC0-1.0
# Database Migrations taste - Keep every schema change in a versioned migration file committed next to the code that needs it. Confidence: 0.95 - Write migrations in plain SQL rather than ORM-generated diffs you have not read. Confidence: 0.80 - Never edit a migration that has already run in a shared environment; add a new one instead. Confidence: 0.95 - Use the expand and contract pattern: add the new column, backfill, switch reads, then drop the old column in a later release. Confidence: 0.90 - Make every migration safe to run while the previous app version is still serving traffic. Confidence: 0.90 - Add new columns as nullable or with a constant default to avoid long table rewrites. Confidence: 0.85 - Create indexes on large Postgres tables with CREATE INDEX CONCURRENTLY outside a transaction. Confidence: 0.90 - Set a short lock_timeout and statement_timeout at the top of each migration. Confidence: 0.85 - Run large backfills as batched background jobs, not inside the migration itself. Confidence: 0.90 - Keep one logical change per migration so failures are easy to read and retry. Confidence: 0.80 - Name migration files with a UTC timestamp prefix and a short verb phrase like 20261017_add_orders_status. Confidence: 0.75 - Prefer forward-only migrations and fix mistakes with a new migration instead of relying on down scripts. Confidence: 0.70 - Run migrations as a separate deploy step before the new application code starts. Confidence: 0.85 - Test every migration in CI against a fresh database and against a copy of production-sized data. Confidence: 0.80 - Add foreign keys and check constraints as NOT VALID first, then validate them in a separate step. Confidence: 0.80 - Rename columns and tables only through a view or dual-write period, never in a single step. Confidence: 0.75 - Store the applied migration history in the database and fail the deploy if it has drifted. Confidence: 0.85 - Review migrations as carefully as application code, with the generated SQL visible in the pull request. Confidence: 0.90 - Keep seed and fixture data out of schema migrations. Confidence: 0.80
© f · CC0-1.0 · f/prompts.chat
