The problem with coming in later is that data models are hard to change once a system is built around them. Sure, a DBA might spend a few days optimizing what's there, but the structure of the model itself is something you'll have to live with for quite a long time. Getting it wrong at the start means pain every time you interact with the database.

This is a real problem, in my book. DBAs also have very specialized knowledge, and tend to be expensive, but they're at their most productive when they're doing schema cleanup and index optimization work that can probably only keep a good person busy for a person-month or two per year, tops. And they're also at their most productive when they are preventing problems rather than trying to clean up stains that have already been set by a mess of runtime dependencies.

And all the rest of the time, you've got a very smart person whose job is basically just to make sure the backups are running smoothly.

I'm not sure what the solution there is. Only the largest enterprises can really keep a good DBA busy with work that isn't just skull-splittingly boring. Maybe merge the DBA role with BI or data engineering?

warehousing, projections, dev ops, cluster management, tools for disaster recovery, chaos monkey. There's _never_ enough time to do everything and I feel that claiming "there isn't enough work to do" is just not taking the subject seriously enough. For fucks sake, most of our applications are effectively just SqlServer value-adds.