I’ve come across quite a few articles on the discussion surrounding the “DBA is Dead” topic. I’d like to open this up for discussion. Perhaps the rumors of the imminent demise of the DBA are grossly exaggerated—or are they?
There is lots of talk about the value of data, the expansion of data, the movement of data into the cloud, etc. However, few of the articles I’ve read discuss exactly how the DBA role will die or change with the advent of database as a service (DBaaS). Let’s dive in!
Admittedly, there will be certain things a DBA won’t have to worry about any longer: installs, upgrades, patches, instance-level configurations or parameter tweaking, infrastructure designed and tailored to your needs (especially storage tiers and RAIDs), fewer architectural decisions, and potentially even database vendor preference. Backups, replicas, and disaster recovery should be verified, but that can be included with the offering.
Okay, so if those are going away, what’s left? Ah, here’s the fun part (to me and hopefully to you): SQL performance tuning, data modeling, indexing strategy, broader knowledge of other technologies (from networking to application logic), and perhaps cost focus. Why do I list the last item? Easy—if the DBA is aware of the different price tiers for cloud-based infrastructure (DBaaS) AND are aware of the things that drive higher tiers, AND can do the tasks above skillfully in order to either reduce cloud tiers or prevent the jump to the next tier… that DBA just became a value proposition to their organization versus a cost center!
The intention of this post is not to provide a definitive answer as to how the life of the DBA will change if your organization starts to leverage DBaaS. Rather, it’s to start the conversation so that perhaps collectively, we can determine which way we should be growing our own skillsets to set us up for success in the future. What are your thoughts on the matter? Are DBAs a dying breed? Or are we morphing into something more? Tell me your thoughts in the comments section below.
Don’t leave your database monitoring behind as you deploy in the cloud! Try a free 14-day trial of Database Performance Analyzer to make sure you have full coverage for everything you are responsible for.- Download Today
DBAs have *always* been a dying breed.
When SQL Server 6.5 was replaced by 7.0, the cry went up, “DBAs? We don’t need no DBAs!” That worked (not). Ditto the move from 7 to 2000 to 2005 to 2008 to….
When SQL Server finally got competitive on scaled performance, Oracle DBAs were supposed to be the dying breed.
When NoSQL, Hadoop, MongoDB arrived, same story.
There’s never been a better time to be a DBA; businesses can keep costs down if they involve DBAs at all stages of the development process, from asking tough questions on row size (do you really need a varchar(max) to store a surname?) to helping craft just enough indexes to get the best performance.
There’s room for all of us, from physical storage engine nerds to performance gurus. We just need to convince management to involve us in all stages of a project. Real DevOps, if you will, rather than DEV_and_we_might_remember_to_involve_the_Ops_guys_at_the_production_deployment_stage.
Bingo! No one needs a dba until they NEED a dba. I’ve seen a recent increase in dba openings especially sr level. This tells me that too many shops have been tinkering around with no dba or low level play around types. There is no substitute for a true dba.
Jenn, Gold star for your answer 🙂
I do not need a plumber till I need a plumber. That spare tire is just a heavy weight till one gets a flat tire. Then the difference between a can of “Fix a flat”, doughnut temporary tire and a true tire is pretty obvious. Ditto for “Google” vs contractor vs on sight D.B.A
.
Well Put Jenn. This level of thinking DEVOPS is where I am positioned. For Prod DBA Ops is slowly being erode by good developers and third party tools.
Hank Freeman
Senior SQL Server DBA (Data and Solutions Arch)
Spoken like someone who gets the value of what DBAs bring to the party!
“Dying breed” – I laugh at thee. The specter of vendor COTS and hosted services was scary till they used it. Then restores, tuning, integration and the two am phone “Your call is important to us. Please leave a message” changed all that.
In my opinion: the lazy D.B.A. will just die quicker. The good D.B.A. is fine. The poor D.B.A. who never focused on performance / maintenance will be overworked and suffer. Why? Management can clearly see “they have so much less to do. We only need one D.B.A and a Jr. backup.” Not!
There are the special battles a D.B.A. wizard is needed for: conversions, corporate consolidations, new projects, fixing “long running support”, hyperconvergence. Yes ORACLE provides the Exadata and ORACLE appliance, but both need a DBA like a race car needs a driver.
BTW, I still run DB2 on z/OS – dying database on the dying mainframe. New version of DB, z/OS and the mainframe are all due out. Due out because mainframes do not get hacked, are very stable and have decades of support materials for the O.S., programs and utilities. No one talks about it, so no one knows about it.
My assertion DBAs are not dead rests on the number of newbies using SQL server who need help and support. YouTube, StackExchange and Google only go so far. Windows server keeps changing as does security. Those with experience often outperform those with a MSDN subscription.
Please take SQL Server, NoSQL, ORACLE, DB2-C (free edition for LINUX, UNIX & Windows) home to play with. I have learned far more installing my own database and solving issues than executing flawless lab exercises – grasshopper 🙂
A wise man once said there will always be new and bleeding edge technology that is sexy, but the world runs on legacy.
Thank you, I will remember that. DBASE-IV, R, Banyon Vines, etc were “new and sexy” but now just historical foot notes.
Also, the new stuff is just implementing the old stuff. VM-Ware had to back off “re – entrant ” code that mainframes have used. Re-enterant? Load a .DLL or OS once and have all the virtual machines execute the same copy. One copy is loaded in memory, not five or twelve. Good way to do more with less.
Hope this helps others make the case for their jobs and having at least two if not three D.B.A.s on staff. Why so many? One thing a D.B.A. provides is tuning to make things run faster. DBAs are a “performance point” that improve the systems. They are not just a “cost center” – in my humble though biased opinion.
R is actually still around. In fact. MS has created Visual R for VS2015
Wow, Visual R. Thanks for the heads up.
Yes there is a Visual COBOL for Visual Studio as well as IBM.
DBA’s are not a dying breed.
Excellent comment.. Fully support it.
Methodology of some of the tasks some DBA’s carry out will undoubtedly change. Currently we might decide how much of what kind of resources we need physically, how the storage is configured etc, in a DBaaS world we’ll still decide how much and what kind of DBaaS we subscribe and provide to our users. The database itself will still need to be designed, tuned and maintained.
I come to this article having just read the breakdown of Amazon’s recent S3 failure. And I wonder, disaster recovery is going to look very different in a DBaaS world, it’s going to be much more complex. We’re going to have to consider how embedded we’re becoming in a single point of failure, how we’ll mitigate in the event of failure.
DBA role will evolve, like all roles do, it’s name might change in some orgs, but it’s unlikely to ever disappear.
Alec,
Thanks for pointing out Amazon failure. There are others – both with and without an onsite DBA.
DBaaS and DBAaaS do work. However they do not seem to have “skin in the game” Working with them they are focused on the big picture – not my little container. Vendor consultants on the other hand have “skin in the game”. One of the best was a PeopleSoft SQL server consultant who saw the small picture. Reducing report run time from four hours to three was a big thing for him. Even bigger for us. BTW, he was the only one who did it. Many tried, many failed.
A good DBA knows the database, the application, the hardware and the rhythm of the customer. When are their busy times. What is their goal. What are they willing to trade off ?
DBA’s and COBOL and Assembly language – ALL DEAD! Just note the hint of sarcasm in this post. And you might guess I’ve been doing this for a long time. COBOL? Assembly language?
It really depends on which end of the stick you are on. Your stick ends may differ from mine but that’s OK.
The good end: Your employer has made large investments in infrastructure and has no intention of moving to anyone’s cloud. There will be change here too. In thirty years, not six months has gone by without something new coming along.
The other end: Your employer is moving to the cloud, and you want to remain a real DBA, then perhaps you should move as well.
Good old Assembler. It’s been a long time. I got into this company partially because someone left and they had ‘lost’ the source code and needed help with the programs.
SQL Server/Databases still need care, management and feeding no matter what.
The blog post makes a big assumption, that being everyone will jump onto the cloud band-wagon. Erm, Rob, perhaps you should take off those cloud colored glasses and look at the entire business world rather than just your part in it.
Over the past 20 years I have seen and worked at companies that run their systems on editions that are not just two service packs behind current but two entire VERSIONS behind what is current. In the real world there are a whole slough of reasons why companies do not upgrade to the “latest & greatest”.
Add to that the companies that are paranoid about security (as we all should be), concerned about performance, control freaks and the list goes on.
I agree that there will be new opportunities for DBAs that want to move on to different sorts of challenges and I may at some point follow them. However, I see that as just another evolution in the world of Data Management and Administration. Once a company realizes that they can not be as competitive with all of their data in the cloud as they are with it on premises they will start looking for that DBA hotrodder to make their data screaming fast as well as highly available.
Good points Richard! In fact, looking at some database data recapping 2015, AWS databases accounted for 2.3% of overall market (up 33% YoY from 2014). Just for kicks, if we assume that growth remains constant, 2016 would be just over 3% and 2017 would be just over 4%. that’s not factoring in Azure at all which wasn’t in the picture in 2015.
Strictly speaking from a database perspective, the main points I wanted to make were:
– companies are looking to the cloud as part of their database infrastructure strategy
– DBAs will have fewer tasks and fewer levers to pull if in the cloud
– many companies have and will continue to bring databases back on-prem from the cloud (for a variety of reasons – security and cost being among the top)
– More and more job descriptions are being written with cloud as part of the desired skills
– Performance tuning will/should always be one of the levers for a DBA regardless of where the databases live.
Great comments/discussions!
So far cloud solutions look good for small companies, one off initiatives, and D.R.
Local governments seem less willing as they want to be up and running even when the internet or internet connection is down. Not just fire, police, courts, or water billing but animal lic as well. Which is odd because unlike a business, cities customers can not just walk next door to another city and pay real estate taxes, or a parking ticket.
DBA will be needed for cloud bases systems as running everything in the cloud. Why? Cost of data transferred. Returning only what is needed, not the whole table or data set, keep the I/O part of the bill lower.
Non DBA folks will not only start with but regularly use: select * from ….. ; No where clause. No select top 10 rows only. Yet they only read the first ten rows to see if this is what they are looking for (sigh)
RIP, DBA.
Surprising no one mentioned “Rapport” or soft skills.
Q1: Do customers value the DBA they know and have worked with v.s. “DBA in a box” ?
Q2: Would it matter if the DBA was a bot? A.I. robot?
Microsoft announced A.I. in SQL server. ORACLE already has “self tuning” Twitter & companies have bots that respond so well people do not realize they are talking to a bot.
DBAs are alive at everywhere.
I’ve gone on a couple of interviews and the interviewer in both cases said “we don’t have a DBA, our databases are in the cloud and an upgrade is as easy as pushing a button and requires no downtime”. It seems they feel they can grab anyone with no experience to fulfill the role of the DBA along with their other every day duties. So from where I see it, the traditional “Full Time DBA” role is dying and most companies will contract a DBA only when they have issues, they will have someone to come in and do some cleanup/tuning and consider it a project that will last 1-2 months.
Ask them who is responsible for disaster recovery of critical data. What do they do when the ‘push button’ software does not work.
Like!
Till a database dies. Say no more.
When end-users stop accidentally clobbering their data or running out of allocated space, stop trying to access data that they are not authorized to or learn enough not to run things that take up ALL space that is intended to be shared by multiple users…maybe the
Nope.
My take on it:
http://dallasdbas.com/prediction-sql-server-dba-role/
TL;DR version: Changing, yes, dying no. 🙂
DBA doesn’t die, they are just victims of the never ending quest to make one employee span several roles. Certainly if you’re the DBA, when you take that hat off, you can do the rest of it. Blame the executives. The jobs descriptions I see is they want a slave, back end to front end. front end to back end and maintenance so the application is instant gratification for a user. Since the finished product has pre-requisites that must be required, the DBA is seen as the master of all of them, certainly when one foundation block is completed, that same person can move to the next phases of the project and maintain or tweak what they’ve done along the way. Anchoring on one player to be the 5 tool player of IT. And of course this is all a $ 30-50/hour job and no benefits position, do it in a few months, mentor everyone else and leave. In that world there are no roles. And then there’s always the several programming languages you’re supposed to be expert in too. Oh by the way, you’re supposed to walk in off the street and make this seam-less transition without ever having dealt with their data sources ? That about nail what you guys see/are dealing with ? The Tyranical CEO & braintrust, those that accomplish by delegating down, wanting IT’s version of baseball’s perfect game without ever having thrown a pitch themselves in the bullpen ?
Without DBA’s who will administer the cloud databases
When you say administer, do you mean patch, upgrade, backup, etc? Asking because administer is a fairly ambiguous term that could incorporate a LOT. 8 )