Thats tricky, maybe hire an DB engineer or ask professionals and partner with them, to train Devs? Restricting them after letting them run loose will make em mad anyway, so what are your concerns? security? performance?

I mean u can put layers on top, like ORMs or graphql stuff like hasura tonabstract access to DBs,or use external managed systems like neondb, supabase or aws/azure own stuff.. to enable restriction on tables and DBs. but this things make management worse if there is no discipline.

Im no DB engineer, just a sysadmin also dealing with same issues, but there is no holy grail. In the company i work for, one Dev who really was into DB engineering took the Owner role and he is discussing engineering, giving access to them and rolling out changes with the the DEVs, when they need something, but not the devs itselfs. He also writes migrations. But he is also a very skilled Dev.

yes, you are doing it wrong right there: database as common infrastructure, and (worse) database with no ownership...instead, you want your backbone components to talk to each other with a messaging system, decouple responsibilities (counterparties, accounts, risk, ...), and give ownership to specific members