New to Claude Skills? Learn how to install them →

jeremylongshore on GitHub

Database Diff Tool

Free

Automate database schema comparison and synchronization.

Get this skill

Free · Opens the source repo

What Database Diff Tool does

The Database Diff Tool is designed for developers and database administrators who need to compare and synchronize database schemas across different environments, such as development and production. This tool automates the process of identifying differences between two database schemas, making it easier to manage changes and ensure consistency. By extracting schemas from both source and target databases, users can quickly identify added, removed, or modified elements, such as tables, columns, indexes, and constraints.

To use the tool, users must have connection credentials for both databases and the necessary permissions to access schema information. The tool relies on standard database commands like pg_dump for PostgreSQL and mysqldump for MySQL to extract schema details. It then performs a comprehensive comparison, generating a structured report that categorizes differences and provides migration SQL scripts to align the target database with the source. This ensures that any changes made in one environment can be accurately reflected in another, reducing the risk of discrepancies.

The Database Diff Tool is particularly useful in scenarios where multiple environments are in use, such as during development cycles or when preparing for production releases. It helps teams maintain schema integrity by providing clear visibility into changes and allowing for easy synchronization. Furthermore, this tool supports rollback operations, ensuring that migrations can be reversed if necessary, which adds an extra layer of safety during deployment processes.

Overall, the Database Diff Tool streamlines the schema comparison process, making it a valuable asset for any team managing multiple database environments. Its automation capabilities save time and reduce the potential for human error, allowing developers to focus on building features rather than managing database inconsistencies.

When to use it

Use this tool when you need to compare and synchronize database schemas between different environments, such as development and production.

When not to use it

This tool is not suitable for real-time database monitoring or for environments where schema changes are frequent and unpredictable without proper migration management.

What you can build with it

Detecting schema drift between environments

After a period of development, use the tool to identify unauthorized changes made directly in production that are not reflected in staging.

Pre-deployment validation

Run the tool before deploying migrations to catch any discrepancies that could lead to deployment failures.

Version upgrades comparison

When upgrading PostgreSQL versions, compare schemas to ensure compatibility and identify any deprecated features.

How to install Database Diff Tool

View source

1. Install with the skills CLI

npx skills add jeremylongshore/claude-code-plugins-plus-skills/comparing-database-schemas --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by jeremylongshore

Database Diff Tool

Overview

Compare database schemas between two environments (development vs. staging, staging vs.

Prerequisites

  • Connection credentials to both source and target databases
  • psql or mysql CLI configured to connect to both environments
  • Read access to information_schema and pg_catalog (PostgreSQL) or information_schema (MySQL)
  • Permission to run pg_dump --schema-only for full schema extraction
  • Understanding of which environment is the "source of truth" (typically the migration-managed environment)

Instructions

  1. Extract the full schema from both databases for comparison:

    • PostgreSQL: pg_dump --schema-only --no-owner --no-privileges -f schema_source.sql source_db and repeat for target_db
    • MySQL: mysqldump --no-data --routines --triggers source_db > schema_source.sql
    • Alternatively, query information_schema directly for programmatic comparison
  2. 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)
  3. Compare columns for each shared table:

    • Query information_schema.columns from 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)
  4. Compare indexes:

    • PostgreSQL: Query pg_indexes for indexname, indexdef on each database
    • MySQL: Query information_schema.STATISTICS for INDEX_NAME, COLUMN_NAME, NON_UNIQUE
    • Flag missing, extra, or differently-defined indexes
  5. Compare constraints (primary keys, foreign keys, unique, check):

    • Query information_schema.table_constraints and information_schema.key_column_usage
    • Detect missing foreign keys, changed constraint names, and altered check constraint expressions
  6. Compare functions, stored procedures, and triggers:

    • PostgreSQL: Query pg_proc for function signatures and pg_trigger for trigger definitions
    • MySQL: Query information_schema.ROUTINES and information_schema.TRIGGERS
    • Compare function bodies for logical differences
  7. Compare enum types and custom types (PostgreSQL):

    • Query pg_type and pg_enum for enum label differences
    • Detect added or removed enum values (note: PostgreSQL only supports adding enum values, not removing)
  8. 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)
  9. 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
  10. 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

ErrorCauseSolution
Connection refused to one databaseNetwork or credential issue on source or targetVerify connection strings; check firewall rules; confirm credentials work with direct psql or mysql connection
Permission denied on pg_catalog queriesUser lacks read access to system catalogsGrant pg_read_all_settings role; or use pg_dump --schema-only which requires fewer privileges
False positive differences from default value formattingPostgreSQL normalizes default expressions differently in different versionsNormalize default value strings before comparison; ignore whitespace differences; compare semantic equivalence
Enum type modification blockedPostgreSQL does not support removing enum values or reorderingCreate a new enum type, migrate the column, drop the old type; document this as a multi-step migration
Generated migration fails on targetTarget has data that violates new constraintsAdd 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

Frequently asked questions about Database Diff Tool

Similar skills