The job of a DBA is a relatively thankless one. To make things easier for all parties, there needs to be a better understanding of where the responsibilities lie between DBAs and applications developers.

Applications should be perfectly capable of maintaining their own schemas and data. A database is just a big variable store, in the same way as are the stack and the heap. It’s a clever store, yes, but still a variable store. The structure of that variable store and the access to it should be governed by the application itself. The application should be able to migrate its own schema up and down in the case of a rollout or rollback, and should need no human intervention for any part of its release.

Making changes to an app’s database outside of the deployment pipeline (for instance, inserting/deleting rows, adding indices or uniqueness constraints etc.), is putting the application into an inconsistent state with what’s in development and what will be deployed when it next goes to production. This isn’t going to help anybody and may end up crashing the app.

A good software engineer will keep mechanical sympathy in mind when doing database work, and will ask for help when out of his/her depth. A good software engineer will know about nth normal forms, indices, sharding and will be as responsible with the database(s) owned by his/her app to the same degree that he/she would be responsible with the stack and heap.

A good DBA will ensure that each app sharing a database server behaves as a good citizen and doesn’t unnecessarily or unfairly utilise resources. A good DBA will be able to help identify and debug poorly-performing queries, and contribute to changing them via the normal build/deployment pipeline.

We can play nicely in the sandpit together. Let’s do that :)