Almost every DBA (both administrator and architect) I’ve worked with was opposed to the workflow that most developers like to use - schema migration tools like

Almost every DBA (both administrator and architect) I’ve worked with was opposed to the workflow that most developers like to use - schema migration tools like Liquibase and FlywayDB along with continuous deployment. I have problems with this approach only if there’s poor testing around database changes and this is the default in most companies. For example, adding an index to a column can write lock an entire table and cause a site outage as a result. On most developer test databases this is accomplished within a few seconds usually in which time most test suites won’t notice the issue. And because most development environments don’t look anything like production for cost reasons, you’re incurring a risk there. Instead of fixing the technical root of why there’s so much risk, most companies add the most possibly expensive resource out there to mitigate or understand it - a person. The more dysfunctional, the more people get piled on while nothing actually is fixed (this is a larger cultural enterprise problem that goes beyond database changes). Most decent data tier engineers I know don’t like to babysit DB changes yet almost everyone I’ve worked with had that as a large percentage of their time spent. Such a waste of time and talent. But then there’s a few DBAs I’ve seen that basically don’t do anything productive by making everything that goes wrong a developer problem, refusing to help troubleshoot (even when the DB in question is not accessible to developers), and other not very devops-y behaviors (hostility-first operations that is). It’d be one thing if the DBs had some huge changes happen, but usually I’ve seen these folks hardly do anything visible to me as another infrastructure guy and the troubleshooting I wind up doing on behalf of powerless developers is something that would have taken someone more knowledgeable less than 5 minutes with a quick trace of DB queries in flight and some historical profiling. But being change review Charlie is something that a lot of people do that, while necessary to some degree, becomes their entire job. That’s just frighteningly dull work to me.