review-compatibility

Check forward and backward compatibility in both directions, verify DDL is safe on populated tables (no NOT NULL without NOT VALID, use CREATE INDEX CONCURRENTLY), and confirm backfills are batched, idempotent, and resumable. Ship the migration separately from the code that depends on it.

A change is backward compatible when old code can still read new data and new code can read old data during the deploy window. Adding nullable columns, new tables, and optional protobuf fields are safe; renames, type changes, and NOT NULL additions require multi-phase dual-write patterns.

Yes. It checks exported function signatures, REST/gRPC endpoint shapes, CLI flags, env vars, config keys, exit codes, and behavior semantics. Breaking changes like required-argument additions or silent default-value flips are flagged with deprecation-based alternatives.

Skip it for in-memory data structures that never cross deploy boundaries, single-binary atomic deploys with no external callers, test fixtures, and internal helpers with no outside consumers. If nothing depends on the prior shape, there is no compatibility event.

On Postgres before version 11, ALTER TABLE ADD COLUMN NOT NULL DEFAULT rewrites the entire table under an exclusive lock. The safe pattern is adding the column nullable, backfilling in batches, then adding the constraint with NOT VALID followed by VALIDATE CONSTRAINT.