What a Schema-Drift Audit Actually Finds

# What a Schema-Drift Audit Actually Finds Taking ownership of a database migration history from a codebase that predates you, the first real question isn't "do the migrations look reasonable" — it's whether the migration files, taken in order and applied fresh, actually produce the schema the live production database is currently running. Those two things drift apart more often than teams expect, and the gap is invisible until someone goes looking for it. ## Why drift happens quietly Drift accumulates from small, individually reasonable actions: a hotfix applied directly against production during an incident, with the matching migration file written after the fact and not quite matching what was actually run. A column renamed by hand in a staging environment during debugging, never backported into a migration. A migration that ran cleanly in every environment except the one where a manual ALTER statement had already half-done its job. None of these are negligence — they're the normal residue of operating a live system under time pressure — but they compound, and nobody notices until a fresh environment built strictly from the migration history comes out different from production. ## Running the audit The audit itself is mechanical: baseline the live schema, replay the full migration history against a clean database, and diff the two schemas column by column, constraint by constraint, index by index. Every difference is either a documented, intentional divergence or an undocumented one — and the undocumented ones are the actual finding, because they mean the migration history can no longer be trusted as the source of truth for what the schema is. ## Why this matters more than it sounds A schema that has quietly drifted from its own migration history is a landmine for exactly one scenario: standing up a new environment, restoring from a migration-only rebuild, or onboarding infrastructure-as-code that assumes migrations are authoritative. Every one of those breaks in a way that's hard to diagnose, because the error shows up somewhere downstream of the actual cause. Running the audit and remediating the gaps before they're needed is cheap. Discovering them during a disaster-recovery restore is not.