comparing-database-schemas
Automates schema comparison and synchronization between different database environments.
Install
mkdir -p .claude/skills/comparing-database-schemas && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4788" && unzip -o skill.zip -d .claude/skills/comparing-database-schemas && rm skill.zipInstalls to .claude/skills/comparing-database-schemas
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Process use when you need to work with schema comparison.Key capabilities
- →Extract database schema definitions
- →Compare tables, columns, and indexes
- →Detect schema drift across environments
- →Generate synchronization migration SQL
- →Validate migration safety
How it works
The skill extracts schema definitions using database-native tools like pg_dump or information_schema queries. It then compares these definitions to identify differences and generates SQL scripts to synchronize the target environment.
Inputs & outputs
When to use comparing-database-schemas
- →Compare dev vs staging schema
- →Sync database schemas between environments
- →Generate schema diff reports
- →Verify environment consistency
About this skill
Database Diff Tool
Overview
Compare database schemas between two environments (development vs. staging, staging vs.
Prerequisites
- Connection credentials to both source and target databases
psqlormysqlCLI configured to connect to both environments- Read access to
information_schemaandpg_catalog(PostgreSQL) orinformation_schema(MySQL) - Permission to run
pg_dump --schema-onlyfor full schema extraction - Understanding of which environment is the "source of truth" (typically the migration-managed environment)
Instructions
-
Extract the full schema from both databases for comparison:
- PostgreSQL:
pg_dump --schema-only --no-owner --no-privileges -f schema_source.sql source_dband repeat for target_db - MySQL:
mysqldump --no-data --routines --triggers source_db > schema_source.sql - Alternatively, query
information_schemadirectly for programmatic comparison
- PostgreSQL:
-
Compare tables present in each database:
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public' AND table_catalog = 'source_db' EXCEPT SELECT table_name FROM information_schema.tables WHERE table_schema = 'public' AND table_catalog = 'target_db'- This reveals tables that exist in source but not in target (and vice versa)
-
Compare columns for each shared table:
- Query
information_schema.columnsfrom both databases for:column_name,data_type,character_maximum_length,is_nullable,column_default,ordinal_position - Flag differences in data type, nullability, default values, and column ordering
- Detect added columns (in source, not target) and dropped columns (in target, not source)
- Query
-
Compare indexes:
- PostgreSQL: Query
pg_indexesforindexname,indexdefon each database - MySQL: Query
information_schema.STATISTICSforINDEX_NAME,COLUMN_NAME,NON_UNIQUE - Flag missing, extra, or differently-defined indexes
- PostgreSQL: Query
-
Compare constraints (primary keys, foreign keys, unique, check):
- Query
information_schema.table_constraintsandinformation_schema.key_column_usage - Detect missing foreign keys, changed constraint names, and altered check constraint expressions
- Query
-
Compare functions, stored procedures, and triggers:
- PostgreSQL: Query
pg_procfor function signatures andpg_triggerfor trigger definitions - MySQL: Query
information_schema.ROUTINESandinformation_schema.TRIGGERS - Compare function bodies for logical differences
- PostgreSQL: Query
-
Compare enum types and custom types (PostgreSQL):
- Query
pg_typeandpg_enumfor enum label differences - Detect added or removed enum values (note: PostgreSQL only supports adding enum values, not removing)
- Query
-
Generate a structured diff report categorizing differences as:
- Added: Objects in source not present in target (require CREATE statements)
- Removed: Objects in target not present in source (require DROP statements, confirm intentional)
- Modified: Objects differing between source and target (require ALTER statements)
-
Generate migration SQL to synchronize the target database to match the source:
- CREATE TABLE for new tables, ALTER TABLE ADD COLUMN for new columns
- ALTER TABLE ALTER COLUMN for type changes, ALTER TABLE DROP COLUMN for removed columns
- CREATE INDEX / DROP INDEX for index differences
- Include transaction wrapping and rollback-safe operations
-
Validate the generated migration by applying it to a copy of the target database and re-running the diff. The second diff should report zero differences, confirming the migration produces the expected state.
Output
- Schema diff report listing all differences categorized by type (added, removed, modified)
- Migration SQL script to synchronize target schema to match source
- Rollback SQL script to reverse the migration if needed
- Side-by-side comparison of differing object definitions
- Drift detection summary highlighting changes not tracked in migration files
Error Handling
| Error | Cause | Solution |
|---|---|---|
| Connection refused to one database | Network or credential issue on source or target | Verify connection strings; check firewall rules; confirm credentials work with direct psql or mysql connection |
Permission denied on pg_catalog queries | User lacks read access to system catalogs | Grant pg_read_all_settings role; or use pg_dump --schema-only which requires fewer privileges |
| False positive differences from default value formatting | PostgreSQL normalizes default expressions differently in different versions | Normalize default value strings before comparison; ignore whitespace differences; compare semantic equivalence |
| Enum type modification blocked | PostgreSQL does not support removing enum values or reordering | Create a new enum type, migrate the column, drop the old type; document this as a multi-step migration |
| Generated migration fails on target | Target has data that violates new constraints | Add data validation queries before constraint creation; backfill default values; handle edge cases in migration |
Examples
Detecting schema drift between staging and production: After 3 months without auditing, the diff reveals: 2 columns added to production manually (not in migrations), 1 index missing from staging, and 3 functions with different implementations. A migration script is generated to bring staging in sync, and the manual production changes are backported into migration files.
Pre-deployment schema validation: Before deploying a release with 5 migration files, run the diff between the post-migration staging schema and the expected schema. The diff catches a migration that accidentally dropped a constraint that a later migration depends on. The migration ordering is fixed before production deployment.
Comparing PostgreSQL schemas across major version upgrade: Schema extracted from PostgreSQL 14 and compared against PostgreSQL 16 after migration. Diff reveals function signature changes for built-in function calls, updated default values for new parameters, and deprecated syntax in stored procedures. Migration script updates function definitions for the new version.
Resources
- PostgreSQL information_schema: https://www.postgresql.org/docs/current/information-schema.html
- MySQL information_schema: https://dev.mysql.com/doc/refman/8.0/en/information-schema.html
- pg_dump schema-only mode: https://www.postgresql.org/docs/current/app-pgdump.html
- migra (PostgreSQL schema diff tool): https://github.com/djrobstep/migra
- Skeema (MySQL schema management): https://www.skeema.io/
When not to use it
- →Comparing actual table data content
- →Performing live database migrations without testing
Prerequisites
Limitations
- →PostgreSQL enum removal is not supported
- →Requires manual verification for complex constraint changes
How it compares
This process automates the identification of schema drift and generation of migration scripts, replacing manual inspection of database structures.
Compared to similar skills
comparing-database-schemas side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| comparing-database-schemas (this skill) | 1 | 27d | Review | Advanced |
| snowflake-semanticview | 5 | 6mo | Review | Advanced |
| setup-timescaledb-hypertables | 0 | 4mo | No flags | Advanced |
| database-schema-design | 0 | 3mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
snowflake-semanticview
github
Create, alter, and validate Snowflake semantic views using Snowflake CLI (snow). Use when asked to build or troubleshoot semantic views/semantic layer definitions with CREATE/ALTER SEMANTIC VIEW, to validate semantic-view DDL against Snowflake via CLI, or to guide Snowflake CLI installation and connection setup.
setup-timescaledb-hypertables
timescale
Use this skill when creating database schemas or tables for Timescale, TimescaleDB, TigerData, or Tiger Cloud, especially for time-series, IoT, metrics, events, or log data. Use this to improve the performance of any insert-heavy table. **Trigger when user asks to:** - Create or design SQL schemas/tables AND Timescale/TimescaleDB/TigerData/Tiger Cloud is available - Set up hypertables, compression, retention policies, or continuous aggregates - Configure partition columns, segment_by, order_by, or chunk intervals - Optimize time-series database performance or storage - Create tables for sensors, metrics, telemetry, events, or transaction logs **Keywords:** CREATE TABLE, hypertable, Timescale, TimescaleDB, time-series, IoT, metrics, sensor data, compression policy, continuous aggregates, columnstore, retention policy, chunk interval, segment_by, order_by Step-by-step instructions for hypertable creation, column selection, compression policies, retention, continuous aggregates, and indexes.
database-schema-design
RepairYourTech
Design database schemas with normalization, relationships, and constraints. Use when creating new database schemas, designing tables, or planning data models for any database paradigm.
Validate with Database
diegosouzapw
Connect to live PostgreSQL database to validate schema assumptions, compare pg_dump vs pgschema output, and query system catalogs interactively
drizzle-orm
EpicenterHQ
Drizzle ORM patterns for type branding and custom types. Use when working with Drizzle column definitions, branded types, or custom type conversions.
database-design
davila7
Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.