What’s the Difference between a Junior and Senior DBA?


senior-dba-characteristics-rectangleI got a great question from a student recently:

In your opinion, where is the distinction between Junior DBA and Senior DBA? I’ve always worked on small teams, so sometimes it’s hard to tell where I fit.

This question makes so much sense to me. On small teams, or where you have funky job titles, how do you tell how “Senior” your skills are?

Here are the “levels” of a DBA:

Junior Database Administrator

A Junior DBA is an entry level position. This person masters reactive work, follows defined processes, and learns setup tasks. The Junior DBA:

  • Triages user issues and handling reactive “tickets”
  • Handles failed SQL Server Agent jobs, including backups and maintenance jobs
  • Sets up new SQL Server instances following a process designed by others
  • Tests and applies patches to pre-production and production environments
  • Carries out defined tasks like managing new users, running established audit processes, restoring databases to other environments as required
  • Gets called in the middle of the night a lot
Me in my MidnightDBA shirt in 2010

Me in my MidnightDBA shirt in 2010.

Mid-Level Database Administrator

This person has lost the “Junior” from their title. They are assumed to have the reactive part of the job down pat– and frequently they still do reactive work. In addition, they are looked to to tweak and improve existing processes, and they define an area of specialization. The DBA:

  • Triages more complex user issues and handle escalations from Junior DBAs
  • Improves existing processes for ongoing SQL Server management
  • Modifes SQL Server configuration in response to ongoing issues and new releases
  • Looks critically at patch release notes to advice when a security update, cumulative update, or Service Pack is critical to apply
  • Identifies the area of specialization (usually one, because they are broad) which is right for them. The DBA tends to gravitate toward issues and configuration in this area and learns as much as they can.
  • Haunts their boss’ doorway and inbox with regular requests to attend conferences or trainings (online or in-person)
  • Gets called in the middle of the night a lot

Areas of specialization include:

  • Performance tuning
  • Hardware / Virtualization / Storage
  • High Availability & Disaster Recovery
  • Automation & code for management of a high volume of instances

Senior / Lead Database Administrator

Senior DBAs define their jobs more, and are more self driven. They are more strategic, and are more likely to point out vulnerabilities for the  SQL Server and recommend improvements even if they haven’t been asked to do so. This position has more political requirements (aka social awareness), and frequently involves mentoring more junior teammates.

Senior DBAs usually do not officially manage Junior DBAs. But they always should “manage up”, or stretch beyond simple daily tasks and advise their management about what’s really best for the business’ data.

A Senior DBA:

  • Acts as an escalation point for issues other DBAs can’t solve
  • Decides when major process changes need to be made for SQL Server management. They may make the process changes themselves, or do a high level design and delegate the implementation.
  • Architects SQL Server configuration for bleeding edge features / new use cases
  • Defines high level standards for SQL Server management (and own responsibility for them)
  • Goes deep into one or more areas of specialization, and own responsibility for tough issues in that area
  • Gets irate if they get called in the middle of the night a lot (generally this means processes aren’t stable and there’s a lot to fix)

Senior DBAs have already figured out how to get a regular budget for ongoing conferences — and probably negotiated that as part of getting their Senior level job. They recognize that staying fresh on new features, new issues, and interacting with their colleagues at these events is critical to staying at their job level.

Although Senior DBAs aren’t managers, they frequently handle fallout related to major issues. This is because the senior members of the team own the processes involved in handling those issues. If more junior members of the team can’t follow the processes, the senior team members need to figure out why, and change something.

What about ‘Architects’?

Some companies have an additional level you can progress to, sometimes called “Architects” or “Partners”. This usually is much like a Senior DBA, but the DBA goes even deeper into one or two areas of specialization.

Architects generally have access to specialized environments for testing and design, sometimes do prototyping or advanced performance testing, and sometimes drive very nice cars.

People don’t call them in the middle of the night much. They’re afraid that means they won’t get to ride in the passenger seat of the nice car.

Here’s how to level up your DBA skills, even if your company doesn’t need a Senior DBA

Some environments don’t require too many Senior DBA skills. If you’ve just got a couple of SQL Servers and a small IT staff, things can stay pretty simple. The more complex the environment, the more those skills come in handy.

However, even in a smaller environment, DBAs can work toward building those skills.

One way to do this is by executing on the right projects at work:

  1. Make sure you truly master all the things a Junior DBA should know. Review my Junior DBA training plan and look for any gaps.
  2. Review your environment for any gaps in RPO/RTO or vulnerabilities to data loss or downtime that isn’t acceptable. Design recommendations to close that gap, and review it with your boss and business owners.
  3. Identify what area you want to specialize in, and starting to build up your knowledge there.
  4. Ask your boss to get involved in budgeting and planning for your SQL Server environment, if you aren’t already doing that.
  5. Design a project to review your SQL Server processes for setup and management and improve them strategically. Make high level recommendations with honest time estimates for how long it will take to adapt the processes, and go over them with your boss.
  6. If you don’t have a budget and plan set for ongoing learning / training / conferences, make a plan to fix that. This will require legwork on your part and persistence, but it’s well worth your time.

Being a Senior DBA requires being both independent and influential. As a Senior DBA, you advise the company about risks and what is best for their data– and that includes training you!

An even better way to do this is to start teaching others in the community about SQL Server. Learn more about this path in my post, “How to Level Up Your DBA Career“.

11 Comments. Leave new

  • It’s color. Senior DBAs are in color.

  • I just put together a development plan to help one of my team members get to “Senior Level” and I think you have hit this pretty spot on. The Senior title comes with a lot more strategic thinking and a broader understanding of technologies across a wider range of features. Also, you’re still grumpy, but you get to show it less 🙂

  • Hi Kendra,

    Can you write a similar post for Database Developers?


  • What if all you like to do is performance tuning, troubleshooting and programming PoC’s (TSQL, C#, PowerShell)?

    Are you still a “DBA?”

    • Whether or not you want to call yourself that depends on your focus. Some people who do that kind of tuning don’t focus entirely on SQL Server, and are also tuning application servers and writing automation for other parts of the environment. If you want to go broad that way, I wouldn’t describe yourself as a DBA, but more of a platform performance tuning specialist.

  • […] I have a list of specific steps you can follow to identify the right projects to propose and work on in my post, “What’s the Difference Between a Junior and Senior DBA?” […]

  • I have always respected your work but the missing piece here (applies to probably over 50% of the dba’s out there who are one pony shows) is understanding the data and the application. For every monster company with several layers of DBA’s there are five companies with only one DBA. The DBA’s at these companies not only performance tune but understand the nature and flow of all the databases in the company and probably has a better understanding of their actions and how they can affect the company as a whole. In most of these cases they not only need to be senior DBA’s but BA’a and PM’s

    • Ooo, interesting comment! I think I should actually write a whole post on this one.

      Digging too much into business rules and doing project management work is the #1 thing that can slow your career growth as a DBA. There’s only so much time in a work week. Committing to take on these roles can lead to some growth in the current position, but this is why a lot of DBAs I meet suffer a lot from “imposter syndrome.” They tell me that they spend so much time doing business-user tasks that doesn’t require DBA knowledge that they don’t have time to build their technical expertise, and they’re scared of interviewing at other companies.

      The big problem with business-user / project management work combined with DBA work is that it doesn’t have a clear career progression. It lacks the people-management experience needed to move into management. The DBA work means there isn’t time to develop the project management certifications to leave the DBA side and grow as a project manager. The project manager side similarly hinders the DBA side – there ain’t no time to become an expert on the basics and also specialize in performance tuning or high availability.

      For people who want to leave the DBA world and become more of a BI developer, there’s a case to be made for learning business processes and the nuances of how data is used as a track into leveraging that knowledge to build BI tools and reporting systems. Business Intelligence is very much its own career track at this point, I’m not including that under “DBA.”

      There’s definitely an art to keeping “role focus” as a DBA. For people very early in their careers, it’s healthy to explore and embrace whatever opportunities come to find out what work you really want to do. But as a mid-level DBA, these extra roles can really hinder technical growth.

      • I am actually in this boat too. We have 2 DBA’s where I work so one of us can take vacations at a time. But both of us are DBA’s as well as developers. It is up to us to make the databases run well, but also to develop applications that use the data (via C#, SSRS, SAS, etc). Getting specialized in a specific field is darn near impossible. I have pushed my boss at the time to get me out to the PASS Summit for the past few years and am very thankful for that. I learned SO much from that and brought SO much back to the company and I learn more each year. But I have quite a few DBA related tasks that I need to address (SQL upgrades… still have a SQL 2000 box sitting around that needs to die a horrible firey death), but focusing on the DBA specific tasks is often seen as a “make work” project by the higher ups. Especially compared to when a production application goes down and the company needs me to fix it (as I am the one who wrote it).

        I am not sure how to properly address this problem at my company. i think the company is too small to have multi-level DBA’s (we have roughly 70 databases on 29 SQL instances… and then triple those numbers for our test/dev systems (roughly 3 copies of each live on test). I know some places have thousands of databases/instances, so our shop is pretty small in comparison. But when you get places the size of the one I work at, role focus is very difficult. And database performance improvements are not always seen by the company. Such as getting a select * on a view to run in less than a second instead of 5 seconds. The SSRS report loads faster, but end users don’t really notice that much.

        I am not sure what the best solution in a small company is to get into a more focused role of DBA and less of an application developer with sysadmin access on the databases. Mind you that is likely a better question for my boss.

        That all being said, I really liked the article. I have a better understanding of what to expect when applying for jobs when the time comes for me to change. I know I am not at the Senior DBA level. I think I fit in somewhere between Junior and Mid-Level actually. But I must be doing something right… haven’t had a “middle of the night” call in ages. And the last one I had was due to an automated alert that I set up. I like to know about problems before the end users do.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.