Keeping Database Schema in Sync With Production

One recurring problem in backend and data engineering workflows is this: We design databases visually. But we deploy them as SQL. Somewhere between diagrams, migrations, CI/CD and Docker environments, things drift. Over time: The ER diagram no longer reflects production. The production schema evolves through manual migrations. Docker setups are maintained separately. Version control contains SQL files, not the original intent of the model. This disconnect is subtle at first. But in real systems, it becomes a source of confusion, onboarding friction, and architectural entropy. Let’s unpack why this happens — and what alternative approaches might look like. The Drift Problem Most teams follow something like this workflow: Initial schema modeled in a diagram tool. SQL exported (or manually written). Migrations handled via Flyway, Liquibase, Alembic, etc. CI/CD pipelines apply migrations. Docker environments configured separately. After a few months: The diagram is outdated. Migrations ref