Application and System: the two types of DBA!

It’s been a while since I posted here… and I just wanted to document something I thought about quite a bit when I was hiring SQL Server Database Administrators (DBA); not every DBA has the same interests, and not every workplace has the same needs for a DBA, and while I initially expected certain things of some DBAs, I was often surprised.

So, please allow me to introduce you to the two main classes of DBA (in my humble opinion, from a limited sample size, etc etc)!

The ‘System’ DBA

The System (or perhaps ‘Infrastructure’?) DBA is a person who — in general — cares more about the database server than necessarily what is on or stored in the server.  They may be very interested in what specific hardware you are using to store data on, what physical drives or connections are made between servers and storage, or servers and other servers… and hopefully they will also be people who are interested in ensuring backups happen at certain times in certain windows.

But my impression is that these sorts of DBAs may work in enterprises where there may be security restrictions on them even being able to see the systems they are looking after, or they look after many systems; and the consequence I believe is that they may not actually know very much about the systems they look after or are called to support.  I envisage the DBA in the large enterprise expects some document or standard to tell them what backup policy to apply; or what recovery window to work towards, and works strenuously to achieve that; possibly with huge hardware budgets to facilitate that.  I imagine the support DBAs at various managed services like Azure, Rackspace, or Amazon are essentially forced into this category.

One of the things that surprised me about System DBAs is that they may not actually care that much for SQL or even be very good at querying some fairly basic queries of application data… indeed a possible consequence of all that high-level thinking and working is that they simply may not expect to have any contact (or interest) in the data in the database at all!

The ‘Application’ DBA

The Application DBA is much, much, more focused on the data in the database as compared to the System DBA.  They will care far more about the elegance and correctness of the data-model, and perhaps even be intimately aware of the system design and so on.  They may even have a very strong understanding of the mechanisms by which the application (even if it is coded by programmers / developers in a language like C#) operates; either because they care and pay attention… or perhaps because they write and maintain the stored procedures and functions that are used to read and modify the data by the programmers.

My sense is that the Application DBA therefore has less familiarity with the underlying hardware, they are probably more likely to rely on ‘managed service’ DBAs to get upgrades and patches applied, and so on.

In short; the Application DBA may associate more closely with developers, and may therefore be less able or equipped to take position on principle such as what way exactly is the ‘right way’ to back-up data.  And they may have less time available to them to apply those sorts of rules because they are helping others write SQL or whatever.


I certainly associate more with being an Application DBA than a System DBA.  That may be as much down to opportunities that have been available to me as anything else… but one thing I really do like is being able to understand the system I am working with, and often I have found myself to be the best person in the busines to query the database, find oddities in there, and from there work outward to identify what might have caused that problem; which is a fantastic thing to be able to do!  However, while my roles as an Application DBA have always been mixed with development roles, I was definitely worried and aware that there may not have been anyone around to argue more strongly for infrastructure updates, modernisation etc.; especially as there often have not been great imperatives to upgrade.

If these characterisations are even slightly true, then DBAs need to start acknowledging these different roles and interests.  It may be important, because there is sometimes a sense among developers that DBAs just represent an obstacle to getting things done than an aid… and I sense that some Object Relational Models (ORM) almost came about to help developers avoid having to talk or deal with SQL and the ‘grumpy DBA’.  There probably needs to be an accomodation between the different skill sets; and whichever field you prefer to sit… at least make sure that you are talking to your neighbours on the other side of the fence!