Should Someone Try to Get a DBA Job?
There was an interesting post on Reddit yesterday asking what DBA jobs are like these days. Here’s a snippet of the most important part:
Our friend works for maybe 15 hours a week, on call for maybe 40 but is always running around not in front of his computer. She works odd hours, takes the shifts like Saturdays and Friday nights…And the rest of the time she watches YouTube/does other things while on call.
Is this true of all Server DBA jobs? I’m genuinely curious, and surprised how someone can be paid 140k a year for working so little. Is it a dying position that can easily be off shored? Enlighten me more, I’m so curious whether all SQL Server DBA roles are like this, or is this a rare occurrence.
There are actually several great questions in that post, and I’m going to reword them and talk through ’em individually.
Do some DBAs only work 15 hours per week?
Yes, and I know a few, but they’re the exception rather than the typical DBA job. In these cases, the DBA has been there for several years, they’re experienced with building their own automation, and they’re the only DBA at a particular stable company (or in a department/division.)
See, good DBAs strive to automate their work, and after a few years in a stable company, the DBA has put enough proactive automation into place to deal with regular issues. The company isn’t adding a bunch of new servers or users per week, so the DBA is just efficiently keeping the lights on.
In these cases, the company is paying the DBA for two benefits:
- The DBA keeps the lights on, reliably
- When things break, the DBA is on call 24/7 to react, and to troubleshoot efficiently using their in-depth knowledge of the company, applications, and SQL Server itself
Can a DBA do the same work for 25 years?
The Reddit post mentioned that the DBA in question got a certification 25 years ago, and they’ve been doing the same work for 25 years.
I can see how a DBA would feel that they’re still doing the same stuff they did 25 years ago. After all, we’re still setting up backups, checking for corruption, setting Cost Threshold for Parallelism, troubleshooting Agent job failures, explaining why SQL Server is slow right now, tuning indexes and queries to make them go faster, filling out reports for security auditors, and answering licensing questions.
However, the way we do those things has often shifted over time.
If you took a DBA from 25 years ago, certified with SQL Server 2000, and asked them why SQL Server is slow right now, they could probably give you an answer – but their answer would likely be different than the one a current DBA would give you. There have been so many slow evolutions over time in T-SQL, wait stats, hardware, diagnostic scripts, you name it.
In the case of the 15-hour-per-week DBA, the way she’d automate her work in the year 2000 is very different than how she’d automate it today. Over the years, she probably dabbled with T-SQL, then batch files, then PowerShell, then the Azure portal, and maybe today she’s learning Python to stay ahead of the game and work with her cloud services.
So yes, you can do the same work for 25 years – but the tools are constantly evolving, and you still have to keep learning.
How do I find those 15-hour-per-week jobs?
Those jobs are not advertised as “work 15 hours per week.” They’re advertised as regular hard DBA jobs with a lot of complex systems that break frequently. The difference isn’t the job: it’s the DBA. The DBA is the one who works hard for a few years to catch up, right the sinking ship, and then put in automation to avoid future problems. (And for those first few years, the job can involve a lot more than 40 hours per week, depending on how quickly the DBA wants to catch up and get ahead.)
That opportunity – to automate most of your work – isn’t restricted to just DBA jobs. A lot of tech administration jobs have that same potential.
Your best bet will be to focus on large, stable companies though. Small and fast-moving companies have too much change, and you’ll never be able to catch up and completely automate your work. There will be too many new incoming servers, too many application changes, too many architecture projects, etc.
Is DBA work easily done remotely or offshore?
The technical work: yes. For years, long before COVID, DBAs fought for the ability to work remotely. We spend a lot of time administering servers, and it’s not like we need to physically touch the servers.
The political work: not as much. Because DBAs play a central role connecting many teams (developers, systems administrators, network admins, project managers, end users, help desk, etc), we often get roped into meetings. Many of those meetings have very high visibility because we work on critical systems, so managers often want people in person for those meetings.
That’s still true for me even today, long after COVID. I specialize in a 2-day emergency consulting engagement, and while most of my clients would rather have me jump in quickly remotely, some require me to fly to their offices to do the engagement in person. It often costs them more than double to have me onsite, and those companies don’t care because the database is so critical to their company.
Is DBA work easily outsourced to another company?
No, but not because of technical problems – it’s because of political problems.
Bad remote DBA companies don’t automate the DBA work to reduce it – because they’re interested in maximizing their revenue. The less work they do, the less they get paid – so it’s not in their best interest to put in proactive automation. Instead, they simply use runbooks to respond to each problem as it happens, generating revenue each time.
Good remote DBA companies want to put in automation to reduce the ongoing work – but bad clients may not let them. After all, the company still probably has their own internal development and customer teams who wanna do stuff to the SQL Server, and they want the permissions to do anything they want, at any time, without interference from the DBA. In that case, the remote DBA company is put in a tough position: restrict the customer’s employees’ capabilities to preserve system reliability, or let the customers’ employees do what they want to keep them happy.
In addition, some managers and company owners are just more comfortable having a DBA on their payroll so that when something breaks, the manager can walk into the DBA’s cube and say, “I know you, I trust you, and I’m making you accountable for this problem. I know you’re going to work on solving this problem, and I know you’re not going to stop until it’s fixed, no matter what it takes, and it’s not going to cost me extra money.”
Is the DBA position dying?
There are two kinds of DBA specialists: production DBAs and development DBAs:
- Production DBA jobs evolved rapidly over the last 5-10 years due to cloud database services
- Development DBA jobs are about to evolve rapidly over the next 5-10 years due to AI
Production DBAs focus on installation, configuration, monitoring, and troubleshooting. Platform-as-a-service databases like Azure SQL DB and Amazon RDS automated some of the production DBA work, like backups and outage troubleshooting. In some companies, the remainder of production DBA work has been merged into systems administration jobs or developer teams.
Development DBAs focus on performance monitoring, tuning indexes, and tuning code. The need for them actually grew with the advent of cloud database services because companies suddenly faced much higher, faster-growing bills. I’ve had plenty of clients who said, “OMG, we thought the cloud was going to save us money, but performance is worse and the cost is higher – halp!”
However, dev DBA work will evolve because:
- Developer tooling will start to integrate good database advice, earlier in the application development process
- Performance monitor tooling will start to integrate good database advice after deployment, recommending code & index changes to help
Right now, as we speak, commenters are frantically typing:
But they missed two important words in the above bullet points:
- Integrate – because the advice needs to come naturally during development and monitoring. I’m looking forward to the day when the user doesn’t have to point at something and ask the AI for help, but instead the AI can simply, politely intervene at the right time and say, “Hey, this thing that’s happening right here, this is a problem and here’s how to fix it.” Microsoft tried it decades ago with Clippy, and it completely bombed, so I know older folks are going to rebel at that solution – but we need that approach, combined with…
- Good – not just advice, but good advice. Today’s LLMs put an awful lot of noise in with the signal, and too much prompting work is required on the user’s part. I regularly use tools like Copilot, and I chuckle and point out that the only reason the advice seems good is that it’s being read through my eyes, and I know which parts to scoff at and which parts to take seriously.
We’re nowhere near either of those today. I hope we will be in 5-10 years.
Should university students aim for DBA roles?
This was really the Reddit questioner’s main challenge, but I couldn’t do it justice without typing all of the above.
Having said all of that, no, I don’t think college students should aim for DBA roles. Those roles are amongst the hardest to get straight out of college because companies prefer hiring DBAs with experience.
I know, I know: “How am I supposed to get experience without getting the job first?” The answer is to get a different job, not DBA, but one where you’re working with data. Gradually gain seniority and confidence managing data, and then over time, where it makes sense, it’ll be much easier for your existing company to promote you into a DBA role.
And good news! Just about all tech jobs these days involve data in one way or another! But just don’t aim for DBA first.
14 Comments. Leave new
A friend of mine not so long ago met a DBA of 25+ years that still uses Activity Monitor and recommends running the missing indexes from the server performance dashboard report…
there are DBAs working for companies for a long time in the same way as long the business is about environment under uber certification and stable process. But its positively the minority.. and i doubt they will be around for much time long.
Oh man, I saw this post on Reddit last night and the only comment was “Not true” and went ‘Yep I have to check back on this one tomorrow, but I’m betting they use Blitz and DBATools!’
I’m glad you picked this one up. I still watch your video snippets you did with Quest on the same topic many years ago where you said “it still can’t reliably order a pizza” and I still somewhat agree with that even today.
Based on your other post regarding MCP APIs I think this is just going to be a very interesting few years for us Development DBAs, and I’m really looking forward to it.
Thanks Brent, great post!
I’m in that “been doing this for a while” camp as well and things have definitely evolved. Some cases are basic – go down to the root cause and see what’s causing your server/database pain, but there are a lot more tools and details to go into now than we had 25 years ago. So the overall concept is still there, but we have more options these days.
I do tend to agree that starting somewhere as a junior, well anything, is really hard. Very few businesses want to take a chance on a fresh-out-of-college person with only that classroom experience. But for DBA work, it’s usually something people fall into – starting in some BA role or dev role or ops roles and taking on more of that database-related work over time. It also means that the mindset of those people should be one of growing skills and knowledge, not “I can push a button”.
I have to agree with the political work as well. It’s possible to grow that side remotely, but much harder. There is a lot to be said for “the C-levels see me and know that things are going well” vs “things are going well and they have no idea that someone makes that happen”. There’s a lot to be said for soft-skills and sometimes people lack those.
“I regularly use tools like Copilot, and I chuckle and point out that the only reason the advice seems good is that it’s being read through my eyes, and I know which parts to scoff at and which parts to take seriously.”
Yep, thanks for taking what I was *thinking*, and putting words to it.
I use AI tools, and same, Brent, same.
Totalmente de acuerdo con todo el post y en lo último que dices es lo que me pasó estando recién graduado, el trabajo más rápido en conseguir fue de desarrollador de software por lo que para dar el salto a DBA pasaron unos 5 años; aunque la experiencia de haber estado en puestos de desarrollo de software me ha ayudado mucho a mejorar mis automatizaciones ya en mis experiencias como DBA
Consider what I’ve done as a path to a DBA role.
My title is software engineer, but I also call myself an ‘applications DBA’ and have for years.
I’m very familiar with SQL Server ‘development side’ items (CRUD, nulls, indexes, t-sql itself, stored procs, views, triggers, etc.) but I couldn’t get certified easily because I know little to nothing about backups, server failure, clustering, hot backups, and other administrative tasks.
However, if I wanted to, I could easily move into a DBA role by learning all of that.
I’m content with what I know already and the development job I’m doing, but…
I have worked with enough DBAs that I could call five of them and say, “I learned all the other DBA stuff and want a DBA job now. Will you recommend me please?” While some may hedge by qualifying what they know I’m good at, I believe I’d be 5/5 for recommendations.
I’m guessing most DBAs don’t work closely with developers – different roles, etc. But when I have reached one with a problem and say, “I’ve solved this problem, but I have to write to tmp and then get it out the way I want. Can you tell me how to do all of this as a set based operation by making it a sub-query? The query works until I make it a subquery. Here’s the code I have written.”
Do that type of thing a few times and you get to a great working relationship with your DBA – because they know you’ve done work before asking them.
My exact path may not appeal at all, but maybe it will give you some ideas.
My personal experience aligns with what you are recommending. I was a developer, who became an accidental DBA. I’m happier being a production DBA rather than a development DBA. I still study and use modern tools, but most of the modern tools lack something or other compared to SSMS & custom TSQL. The Azure tools are similar but different and they’re still developing. I have studied the Azure SQL world for the past decade+, but I’m still a neophyte to the interface.
Same for me, different track. I was a System Admin who got SQL server dropped in his lap. My 1st employer moved from AS400/DB2 to Windows SQL Server. The question went out “Anyone know anything about SQL?” I raised my hand (I’d read a book about the SQL language while in college in the early 80’s). From there on I’ve been the SQL guy at every company I’ve worked for. Always a 2-hat job! System Admin/DBA! I’ve worked for some fairly big companies, and we’ve never had a full time DBA, just me!
Hi, I work for a managed services company that provides DBA support to our customers. We are specialised, we provide just operational DBA support, we don’t touch the data or the application layer. We arrive with a set of robust monitoring tools and when we onboard customers, we health check all the monitored systems are provide a list of fixes or changes that we recommend. Some of the recommendations are actually requirements for the system to enter support.
Why does this matter?
Out customers are very different. Different in scale and different in ability. Some just want us to provide their 24×7 cover and slot into their existing tech teams, and some want us to “do everything database”. On top of that some customers are just noisier/busier than others. This means that customers can vary from the 5 hours per week guys to the 20-30 hours per week guys. Its the tools and sanity checks that let us handle that variety. On top of all of that, I would say that a good 30% of my job is answering questions and talking to the customers. And you will need a broad skillset to cover that part of the job just due to the variety.
So yes, like Brent says there are 15 hour per week jobs, but only if you have stabilised the system first. Then I would expect to add another 5-10 hours per week to that just fielding questions. But equally, you may find that when the DBA that set all that up leaves, the company starts to look outside to managed service companies to fill the gap rather than for another internal resource. Its how we have ended up with a team of 6 supporting 40+ customers.
My advice to anyone who wants to get into the IT professions at any position is.
Get your foot in the door! Take a Help Desk position! I believe every person starting in IT should spend time in the Help Desk. It gives you an understanding of what “your screwups” can cause for other people!
Move up the ladder every chance you can, take advantage of any training opportunities, make your management aware of your goals and (subtlety) that you will achieve them here or somewhere else.
Get experience/knowledge in areas outside your chosen skillset. If you goal is to be a DBA, also learn about servers and network infrastructure, application development. You don’t have to be an expert, just get the knowledge so you know how these things effect your job, and you can communicate with those teams effectively!
I spend about 5-10 hours a week, on average, doing DBA work. I spend up to 15 hours a week doing administrative stuff (I supervise a team of non-DBAs as well as manage all our department’s database servers and co-manage our team’s budget, meetings, etc.). And I average a couple of hours a week doing non-DBA technical things — Active Directory, server updates, and other chores anyone with admin rights can do, but I take on that work because I’m probably the least busy person on my team.
So I’m definitely in that category of 15 or fewer hours a week of honest work. I work for a public-sector department, not for a central IT team. And just like Mr. Ozar says, I spent my first year scrambling to literally find the database servers (no one could tell me where they all were) and get them running smoothly.
Since almost all of our databases are vendor-designed rather than in-house, my performance tuning measures are minimal — a few indexes, but I can’t redesign the usually crappy schemas I’m provided. I do sometimes provide internal “consulting” on things like custom report queries, which is technically DBA Dev work, though I’m primarily a production-focused DBA.
There are days when I’m bored. I spend those days giving myself programming challenges so that I 1) look busy and 2) don’t completely lose those non-SQL IT skills. I also try to keep up on the new stuff, though we have a very small budget when it comes to cloud services so I don’t often get to play in those sandboxes.
But basically, yes, it’s possible. How I got here has been more luck than skill, though. I began doing mostly desktop support and just kept absorbing more skills until I found this job. My pay isn’t in the 140,000 range at all and never will be, but it’s more than enough to make me reluctant to find something that pays more, because it would be some serious culture shock to dive back into a job that makes me work for a living.
Setting Cost Threshold for Parallelism is what I do all day every day, sir. 10 years straight, still hard as a nail.
I think DBAs are firefighters, we work hard when there is a problem but make the equipment is ready when it is needed. The equipment is the knowledge you have to fight the fires. My mornings consist of making sure there is no fire going on with the DB Servers, then move on to working projects with my afternoons being about learning something new.