Prompt·Rebuild and safe change·PG17
Are our database changes safe before we merge?
A migration, or a change to functions, views, RLS, types or column meaning, is about to ship.
Prompt
Review this database change against the live schema, existing consumers, prior migrations and deployment process. Establish whether it preserves current records, supports old and new application versions during rollout, and can be verified on an isolated database. Identify the smallest necessary migration and a realistic recovery path before approving it.
- What it returns
- The migration diff, the consumers it touches, how old and new app versions coexist during rollout, locks and rollback, and a replay on a separate database.
- Skip it when
- The change touches no schema, functions or policies.
- Avoid
- Claiming a rollback exists because the application code can be reverted.
- Changes
- Tests on a separate copy
- Sessions
- Look first, then fix in a new session
- Tools
- Needs: the repository, read-only access to the live schema and a separate database to replay the migration. Helps: pgTAP and, on Supabase, Advisors and branches.
- Works on
- Any PostgreSQL host: Supabase, Neon, RDS, Cloud SQL or self-hosted.
Related prompts
- Database changes during a deployPromptChecks that each database change works with the old code that is still live while a release finishes.
- Why production might not match mainPromptLists every way 'merged' can fail to mean 'live'.
- Settings that differ in productionPromptFinds settings that behave differently in production than anyone expects.
- Can we rebuild this database from its sources?PromptYou worry about disaster recovery, production-only state, or whether the data could be rebuilt.
More in Rebuild and safe change.