The better way is for nobody to have direct write access to the database, but instead for automated tools to do things like that, using reviewed code and config and writing an audit log of actions taken. The trust thing is part of the reason this is a good idea, but it's mostly a good idea to avoid good-faith accidents. I think it is common for companies that haven't yet had time to build those automated tools to delegate their work to senior, very trusted, engineers. But that's not a good solution, it's just more expedient, and a bit better than the database being world-writable, which is a bad solution.

I'm in a small company in that position, what's also helped is wrapping UPDATE statements in a transaction with a verification SELECT statement to make sure everything worked ok, then committing the transaction.

Saved my bacon more than once!

Many companies do not provide read access to application databases either, without explicit consent via well-defined process. There are many compliance-related reasons why this is implemented, one of which may be the protection of your customers' financial performance data.

Yes, it's pretty common not to provide direct access to production data in general.

In my experience, migrations are usually part of the code base, evaluated as such with PR and whatnot, and run automatically when deploying.

It depends on the size and context of the company, but I would not necessarily see this as a lack of trust.

Anyone who removes the "you break it, you bought it" scenario by denying you access to production is actually doing you a huge favor.

Why is this not automated?