Catching Schema Drift Before It Hits Production

Practices
Atharv Mahajan·

Last October, a seemingly innocent migration renamed a column in our events table. It passed code review, passed tests, and deployed to staging without issues. In production, it broke 340 workspace automations that referenced the old column name.

That was the last time it happened. Here's what we built.

The schema diffing tool

We built an internal tool called schemaguard that runs in CI on every PR that touches a migration file. It compares the proposed schema against the current production schema and flags three categories of changes:

Safe: Adding nullable columns, creating new tables, adding indexes.
Warning: Adding NOT NULL columns with defaults, renaming with aliases.
Breaking: Dropping columns, renaming without aliases, changing column types.

CI pipeline with schemaguardPR openedschemaguardSafe ✓Breaking ✗Caught 14 breaking changes in the last 6 months — zero reached production

Results

Since deploying schemaguard six months ago, we've caught 14 breaking schema changes before they reached production. Three of those would have caused data loss. The tool adds roughly 8 seconds to CI time — a worthwhile trade for zero schema-related incidents.

Atharv Mahajan·
Copy link