A DBA on your Project?
Developers usually have some problems with databases, no news. Databases are complex tools, and that's why we have people specialized in such tools, we call them DBAs (Database Administrators). When I did my course on Oracle Database Administration the instructor always emphasized that the DBA duty is "to keep the database available, even after a disaster". Its a fair statement, databases have to keep the data available, if not, most applications will just stop working.
Grow the environment to hundreds of developers, dozens of projects, legacy and new stuff been done. What happen? The databases turn into a thing too complex do deal with it. DBAs, have to keep a close eye on it, knowing if a new functionality can be hosted without break old one, making the old data perform better for the grow of data and always with backup strategies in mind. I agree that's a plenty of stuff to worry about and you should definitely keep DBAs looking into that. But what follows from that is a more and more complex database environment. Now the DBAs have more and more work to do while they are asked to tweak the database for this and for that.
The problem starts when, on a complex structure, you put developers coding new stuff in one side and DBAs are in other side. Developers have too access the data some way but they not aware of whole structure of the database, DBAs on the other side are not aware of the new stuff that is been developed. The direct consequence is a immediate problem in communication, one doesn't know what the other is trying to achieve, and in this scenario usually they communicate too late. In software development, and most areas, communication problems is something you want to avoid. Having late communication makes the solution usually not optimal and takes more time.
What I think that could mitigate this is assign a DBA for each new project. The DBA doesn't need to be exclusive for a project but should participate of stand up meetings, retrospectives, know about the stories been developed, have the context of the project in general and be available for developers to answer questions, even pairing if the developer is coding an access layer. Meanwhile, the DBA group should exchange information about the projects explaining what changes are coming, how to prepare the data structure to accommodate better queries and how share the knowledge to developers about the data and how is stored.
Obviously the main task of the DBAs (keep the system available) is still the most important, but you should have a core group working on that and others sharing time with development projects, than rotate the team from time to time. This probably will increase the number hired DBAs but the benefit, I think, will pay itself in productivity and maintenance cost. As we say in Agile "If it hurts, do it more often."