Job Duties for Database Developers, Development DBAs, and Production DBAs
At the start of my classes and calls, I ask folks to introduce themselves – not by what it says on their email signature, but by the kind of tasks they spend most of their time on. Here’s what I show onscreen to help illustrate it:
Down the left hand side of the screen are the list of things involved with building and hosting a database application. Developers generally start their careers from the top and work down, gradually getting more involved with the database engine. Systems administrators start from the bottom and work up.
Sometimes folks will say, “I do all that stuff.” Yes, of course you know how to do all of that, but pay attention to what it says inside the boxes: which ones do you do daily, versus just every now and then? Like me, sure, I can design a table – but I don’t do that every day.
When you’re a junior jack-of-all-trades in a shop with just a couple/few database servers, you do whatever gets thrown your way. You find yourself jumping around from task to task. You tend to Google everything you’re doing, making sure you’re doing it right, and reading as you go. I used to be the guy responsible for the servers, the desktops, the printers, cobbling together a web app with “Classic” ASP (and I use that term very loosely), and oh yeah, the database server. However, that job role is not database developer, development DBA, nor production DBA. It’s just jack-of-all-trades.
All 3 of those positions – database developer, dev DBA, and prod DBA – can make good money, as evidenced in our annual salary survey. But as you’re thinking about your future career direction and the next job role you want to take, think about which of those duties you love doing the most – the ones you’d want to be doing daily – and that determines where you’ll be the happiest.
Generally speaking, for every 20 developers that you have, you’ll probably need 1 full time database development DBA (aka Dev DBA). 20 people slinging queries can easily keep 1 person busy full time monitoring those queries and tuning them. If you don’t have this position, you’ll likely spend more on hardware running those queries, plus more time troubleshooting questions around why the application is slow. It’s just a matter of choosing whether you want to spend the money on the Dev DBA role, or spend the money on hardware & licensing.
If those 20 developers haven’t been to any formal T-SQL authoring or tuning classes, haven’t read Itzik Ben-Gan’s books, etc, then you may need even more Dev DBA time.
13 Comments. Leave new
A developer monitors performance daily if they’re a worthy developer. Autotrace is good to have enabled for spotting silly execution plans. After the system is tuned and the schema is analyzed, it’s up to the developer to make final query tweaks using hints and whatnot.
A lot of this is going to depend on the environment. When I was a development DBA we had 300+ clients. As a developer I did care about performance but if a particular client’s system started running slow their IT staff was the first stop with our support being the second. Development looked at aggregations across all clients or particular issues that support passed along.
I reference this chart frequently. And just had an occasion to reference it again today.
It occurs to me that the skills listed for Developer / Development DBA thrive with any migration of an existing product to a managed cloud offering.
(personally I’m fortunate that’s true)
Thanks, glad you like it!
I made the conscious choice to specialize in the dev DBA role when I saw the writing on the wall for managed cloud offerings (plus I got sick and tired of fixing Availability Groups.) The Dev & Dev DBA roles even become more valuable in managed cloud offerings!
I’m had to generalize again when I was contracting, but I’m moving back to Dev DBA now I’m salaried again. I just enjoy it more.
Hi Brent. Have you thought about adding a column for the new-ish title and role of database reliability engineer?
That’s a great question – what would you put in that column?
Database reliability engineer is just another fancy title for a production DBA
DBRE / SRE are not the same as the traditional prod DBA roles. Well depending upon the company size. As the name suggests, it focuses faror heavily on the engineering side whereas the pure prod DBA, tends to focus more specifically on the tasks listed above.
DBRE Tasks could listed as
Templated installs
This includes standardised install to deliver a CIS or other hardened build
Templated jobs for backup, dbcc, stats & reindex. All of this need to be able to take custom config so that they are specific to the AGs / apps / DBs requirements.
DBRE is about identifying Dev requirements and building solutions, for example self-service restore portals, aggregating stats within a time series DB and building out graphs e.g. Grafana. Upskilling to kubernetes for postgres (CNPG deployments). DBRE is not just a glorified name for a prod DBA, a DBRE or SRE role, done properly,
can remove 100s of man hours from an enterprise plant.
I guess I am a DBRE without even knowing it. I was templating and automating to make my job easier and my teams tasks easier.
Development DBA is the most interesting and fun for me. Getting exposure to the other areas has been tough in my current company. Starting down the Azure Certification path to at least get book knowledge even if real world experience isn’t possible yet.
[…] Want a production PostgreSQL DBA job? Kubernetes is on its way to being the new standard HA technique, and your job skills will be more valuable if you have a T-shaped skill profile with a specialization in Kubernetes. (I’m emphasizing this only for production DBAs here: prod and dev DBAs are different and have different job duties.) […]
Soon, we will need a Fabric Administrator… Thanks for this, still valid after all these years!