postgres-database-migration
Use this skill for planning, testing, and safely executing PostgreSQL schema migrations — especially when working with production data or shared databases. **Trigger when user asks to:** - Test a schema migration before applying it to production - Add, remove, or rename columns safely on a live table - Change a column's data type without downtime - Add or drop indexes, constraints, or foreign keys on large tables - Understand which ALTER TABLE operations lock the table - Roll back a failed migration - Plan a zero-downtime migration strategy - Fork a database to test a migration safely **Keywor
npx skills add timescale/pg-aiguide --skill postgres-database-migration --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Describes risk assessment, testing against real data, and safe execution patterns for PostgreSQL migrations. Provides concrete guidance on lock behavior, safe vs. unsafe DDL patterns, backfill, validation, rollback planning, and transactional strategies.
How it works
Outlines fast/non-blocking and slow/blocking DDL operations with explicit lock levels for each change (e.g., ADD COLUMN, DROP COLUMN, CREATE INDEX CONCURRENTLY, etc.). Provides safe migration patterns for adding/dropping/renaming columns, changing types via backfill and column swaps, adding NOT NULL constraints, adding foreign keys and indexes, redefining primary keys, and dropping constraints. Includes sample SQL snippets demonstrating safe and unsafe approaches, backfill strategies, and validation steps. Describes two execution approaches: wrapping all DDL in a single transaction or running separate transactions, along with their tradeoffs. Emphasizes rollback planning, validation queries, and the option to fork databases for testing. Mentions dealing with long-running queries and the use of lock_timeout and statement_timeout.
When to use it
Triggered when planning or executing migrations, testing migrations against real data, or for zero-downtime deployment plans. Also applicable when forking a database to test migrations safely, or when rollback and validation steps are required.
What it can touch
Contains references to commands and scripts such as:
- SQL statements like ALTER TABLE, CREATE INDEX CONCURRENTLY, DROP CONSTRAINT, VALIDATE CONSTRAINT, ADD CONSTRAINT, BACKFILL patterns, and various column/type changes.
- Validation and backfill guidance references (no external tools listed beyond standard PostgreSQL operations). It specifies use of SQL snippets and catalog-level notes.
Caveats
Notes that some operations lock tables for extended periods and can block reads/writes, with explicit lock-level guidance. Includes warnings about unsafe patterns (e.g., full table rewrites on large tables) and the need for application coordination when dropping columns. Recommends forks for testing and outlines irreversible operations requiring restoration from backup or fork. License not stated within the section.
# PostgreSQL Database Migrations A schema migration that works on an empty dev database can fail, lock, or corrupt data on a production table with millions of rows. This guide covers how to assess risk, test against real data, and execute migrations safely. ## DDL Lock Reference Every schema change acquires a lock. The critical question is: **does it block reads and writes, and for how long?** ### Fast, Non-Blocking Operations These complete in milliseconds regardless of table size. They only hold a brief `AccessExclusiveLock` for the catalog update, not for data rewriting. | Operation | Lock Level | Notes | |-----------|-----------|-------| | `ADD COLUMN` (nullable, no default) | `AccessExclusiveLock` (brief) | **Fast.** No table rewrite. Metadata-only change. | | `ADD COLUMN ... DEFAULT x` (PG 11+) | `AccessExclusiveLock` (brief) | **Fast.** Non-volatile defaults stored in catalog, not backfilled. | | `DROP COLUMN` | `AccessExclusiveLock` (brief) | **Fast.** Column marked invisible; space reclaimed by VACUUM over time. | | `SET DEFAULT` / `DROP DEFAULT` | `AccessExclusiveLock` (brief) | Metadata change only. Does not touch existing rows. | | `CREATE INDEX CONCURRENTLY` | `ShareUp
- DDL Lock Reference
- Fast, Non-Blocking Operations
- Slow or Blocking Operations
- Safe Migration Patterns
- Add a Column
- Drop a Column
- Rename a Column
- Change a Column Type
- Add a NOT NULL Constraint
- Add a Foreign Key
- Add an Index
- Add a Unique Constraint
- Redefine a Primary Key
- Drop a Constraint
Dump your production database pg_dump -Fc my_app_db > backup.dump Restore into a test database createdb migration_test pg_restore -d migration_test backup.dump Or clone from a live database (requires downtime on source during copy) createdb migration_test -T my_app_db
What does the postgres-database-migration skill do?
Use this skill for planning, testing, and safely executing PostgreSQL schema migrations — especially when working with production data or shared databases. **Trigger when user asks to:** - Test a schema migration before applying it to production - Add, remove, or rename columns safely on a live table - Change a column's data type without downtime - Add or drop indexes, constraints, or foreign keys on large tables - Understand which ALTER TABLE operations lock the table - Roll back a failed migration - Plan a zero-downtime migration strategy - Fork a database to test a migration safely **Keywor
How do I install it?
Run `npx skills add timescale/pg-aiguide --skill postgres-database-migration --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From timescale/pg-aiguide, a repository with 1,806 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.