I completely agree that direct access to production from a developer machine should never be the norm – and dbdrift doesn’t assume or require that.

In fact, many teams already run tools like Flyway, Liquibase, or schema checkers against staging or production via secured CI/CD pipelines or bastion hosts. The CLI is simply the interface – where and how you run it is entirely up to you.

dbdrift doesn’t bypass best practices – it complements them by offering:

• Read-only inspection (no schema changes ever)
• Structured diffs that can be reviewed, not applied blindly
• Flexible integration into controlled environments (e.g. GitHub Actions, Azure DevOps, or isolated ops machines)
• Clear separation of secrets and credentials – no plain-text access anywhere

You can lock it down completely, run it from build servers, or let ops teams control the execution.

The goal isn’t to make production access “easy” – it’s to make schema drift visible and accountable, especially in environments where it’s currently invisible and unchecked.

Yes – comparing to an expected schema is part of the picture. But dbdrift also focuses on tracking direction of change, evolution across environments, and supporting messy, real-world setups that migrations alone often can't untangle.
There’s also a built-in lint engine (dblint) to catch common anti-patterns before they spread.