It's actually fine to have multiple people get access to production databases, if you have an automated change management system. Change Management authorize s

It's actually fine to have multiple people get access to production databases, if you have an automated change management system. Change Management authorize sactions which could be problematic by vetting them through a process. The end result of the process is more confidence in the change: we know who's making it, when, where, why, what the impact will be, what we'll do if it goes wrong, etc. If the change looks stupid, dangerous, or uncertain, it gets rejected. If it looks good, it gets approved. The appropriate access is doled out temporarily to make the change. In this way, Larry the Janitor can deploy changes to your prod db, and you can be just as certain (maybe more so?) about the outcome than if your 10x developer were doing it. Just one example of this is Terraform applies. By loading your changes into a .plan file and requiring approval of the .plan, you know for certain what actions are going to be taken and approve only those. (That doesn't stop Terraform from totally hosing your system due to all the ways it can't predict the outcome of its actions, but at least you know what the intention was)