A lot of answers here entertain the idea that DBA role are disappearing...
I would argue that it's way more accurate to say this role is actually outsourced in most organizations with all the tradeoffs that come with that strategy. I begged my former employer to subscribe to a good PostgreSQL support company. Guess what the one we picked is constantly looking to hire new DBA to sustain growth...
I was in database engineering/administration position for the last 10 year on a small company. It was exhausting because management wouldn't care to rely one guy to manage the whole data stack. It was rewarding because the CEO saw me as probably smarter than I was because I knew SQL well enough to produce outstanding value as a single individual.
Often reading HackerNews I felt like an imposter because NoSQL was the new hype and database was seen as a thing of the past... well trends reverse... and people will always need reliable systems to handle business critical data.
So maybe in a few year after few major Cloud data horror story DBA will become the new trend. No one know.
But learning how to handle data? That will always be handy no matter the underlying technology.
> this role is actually outsourced in most organizations
Or in-sourced to developers. In places I've worked it was a developer's responsibility to ensure that a DB is used properly. None of them knew the DB good enough (they need to write code and have no time to read DB docs) so the result was mixed at best.
This is my experience as well, I spent a few years complaining that my colleagues didn't know their database well enough, and it was causing unnecessary bugs and poor performance.
I wanted the company to pay for some basic courses on the databases we were using, especially for the more junior Devs.
Instead we switched database like 11 times and now I don't know the database either.
Same at my previous role - we did have some people who were really good at some point, and into DBs. We had a very solid Redis and PostgreSQL set-up, and some advanced stuff for simple data in Redis - but once that knowledge fades with attrition, making space for continued personal development into how two very different DBMS work for a small team is not easy, and it just stays untouched, disliked, and somewhat abandoned forever more.
Particularly in places with dedicated DevOps people.
It is common for DBA work to be split between infrastructure and dev teams, without a dedicated DBA though perhaps with one or more particular devs acting as a local database “expert”. In a well run organisation those teams will communicate well, how often this works so smoothly in practise I'll leave as an exercise for the reader to investigate!
Yeah, everybody thinks that their cloud database dujour has them covered. Then by accident they learn that it was not automatically "highly available" and that they need to restore from backup...yesterday's backup...and yes, the laws of physics still apply (the database doesn't index itself).
There are a staggering amount of configurations resulting in a number of states, most of which are not desirable for anything beyond the dev environment.
Senior devs think you're a fucking wizard if you understand 20% of it. Scary.
I'd say the role is morphing. Organizations need employees who would be able to ensure consistent practices, automation, compliance on top of cloud solutions. At some point of scaling the team, having a few DB experts will increase efficiencies and ensure that practices are automated, documented, and taught to engineers compared to letting engineers discover these on their own.
Next, the DB experts help improve efficiency. It's too easy for engineers to over-provision a DB instead of rewriting the query or adding an index or two. Lastly, engineers flock to new datastores on the Cloud that may not be the best fit for the use cases at hand. So advising teams on which datastore to pick is another angle of the role.
> Next, the DB experts help improve efficiency. It's too easy for engineers to over-provision a DB instead of rewriting the query or adding an index or two. Lastly, engineers flock to new datastores on the Cloud that may not be the best fit for the use cases at hand. So advising teams on which datastore to pick is another angle of the role.
Moreover, involving this group of people in design processes will keep you from creating wildly expensive and unnecessary systems. I can't tell you how many times I've seen projects start using wildly expensive Neo4j and a bunch of cutting edge research/non-production dbs (and all of the associated operations work to productionize and software written to utilize) all to end up getting migrated back into Postgres once performance barriers get hit somewhere and engineers realize that Postgres can handle the use case just fine.
On a big database migration a few years ago where I was working, the “solution” was to assign one of the engineers the DBA-ish role for the duration of the project. Turned out to be a bad idea, but he did his best.
If we had had anyone who was actually good at that stuff, besides the few top people who were needed elsewhere, that person would have emerged a hero.
DBA is one of those roles that needs a few years to come back into fashion. Once people realise how incredibly terrible the "new" paradigm is, it will come back in vogue.
It will be while before people pay 100k+ to hire somebody to administering something that you can get from any PAAS in a form where it does not need that. Even if you self host, this is not a thing anymore.
These days you get devops people or data engineers.
I'm not sure if "disappearing" is the right word, but it is definitely moving towards also requiring reliability engineering / stronger than usual automation skills.
It's also a role that's thinning out, because these managed offers are good enough a lot of the time and developers are using the most common parts of the feature set on offer.
I've read a take on NoSQL that it's aimed at web developers who don't want to understand or work with a proper database. I find that in a lot of businesses, the core data is still a regular database, with NoSQL databases only used for non-critical data; it ties in to CQRS as well, with writes being done to a central database, and a read-only cache like redis being used to provide data for the client-facing applications.
I would argue that it's way more accurate to say this role is actually outsourced in most organizations with all the tradeoffs that come with that strategy. I begged my former employer to subscribe to a good PostgreSQL support company. Guess what the one we picked is constantly looking to hire new DBA to sustain growth...
I was in database engineering/administration position for the last 10 year on a small company. It was exhausting because management wouldn't care to rely one guy to manage the whole data stack. It was rewarding because the CEO saw me as probably smarter than I was because I knew SQL well enough to produce outstanding value as a single individual.
Often reading HackerNews I felt like an imposter because NoSQL was the new hype and database was seen as a thing of the past... well trends reverse... and people will always need reliable systems to handle business critical data.
So maybe in a few year after few major Cloud data horror story DBA will become the new trend. No one know.
But learning how to handle data? That will always be handy no matter the underlying technology.