As I navigate further into my career, I’m finding the scope of my role has shifted over the years. I thought I’d take some time to help relay the differences I’ve seen between traditional database administrators (DBAs), database reliability engineers (DBREs), and site reliability engineers (SREs). Joey D’Antoni recently explained what an
SRE does here:
What Is Site Reliability Engineering (SRE)? The SRE Role Explained
Before I start, I want to get a disclaimer out of the way: some of the comparisons here reflect only what I’ve seen and may not match what you’ve experienced. Please assume every sentence starts with “Typically, …” and I’m not trying to generalize or claim anything I’ve seen is better (or worse) than anything you’ve seen.
But how does this compare to my current role (DBRE) and, further, to a DBA role? It comes down to multiple things: responsibilities, skills, and mindsets. This can be different from company to company—some places have DBAs who are DBREs but don’t know it or don’t think about it that way. In
a recent interview, I explained how a DBRE might have a slightly higher-level view than a DBA in terms of overall architecture and future direction, and they may perform fewer everyday tasks that are operational or firefighting in nature. Though I can tell you from experience, we help with those too.
In my current role, being a DBRE is fully inclusive of a DBA’s responsibilities—we haven’t traditionally had someone who was “just” a DBA, due to our architecture. We optimize for end-user load time; queries are in the application code, so development, testing, and tuning has been handled primarily by C# engineers. At other places, DBAs may play a more direct role in making schema changes, reviewing and approving queries and tuning performance on top of managing availability, security, backups, and so on. A DBA might ensure a specific server has a configuration that makes sense, while a DBRE steps back to ensure all servers have consistent settings across the environment and to automate the process of keeping them that way. This was actually one of the first projects I took on when I started at Stack Overflow, which I talked about in a
previous article. We’re still working on the automation part.
Back to a higher level, this is where the SRE role comes in, as there are different types of optimizations required when you want to prevent the database from being a bottleneck. We focus on the deep technical knowledge on the database side, and they focus on the deep technical knowledge of everything else. Networking, caching, queuing, and searching all become key elements at our scale compared to a traditional client-server application. We use Redis and Elasticsearch, for example, to minimize database load—SREs and engineers configure and maintain those parts of the architecture, but DBREs (and/or DBAs) need to have at least some peripheral knowledge about them. We often collaborate with those teams to understand current and future needs in terms of scalability and environment or to troubleshoot problems in real time. For future needs, some short- or long-term changes may involve moving from Windows to Linux, migrating to the cloud, or implementing stronger security (TLS/Always Encrypted). These are “all hands on deck” changes.
DBRE vs SRE
I asked several people in the industry how they thought DBREs and SREs differ, and I wasn’t surprised by anything I heard back. Here are some of the more interesting quotes:
Michael (SRE):
“SREs apply software engineering to the problem of operations so the number of humans scales sublinearly to the number of systems and services being operated. I think a DBRE would be the same, but replace ‘systems’ with ‘data.’”
Angela (DBRE):
“Though DBAs and DBREs are subject-matter experts (SMEs), SREs have to be generalist SMEs, as we’re responsible for database health and wellness, data processes, data reliability, applications, Windows and Linux networks, services, deployments, and the overall health of the development and operational environments.”
Andy (DBRE):
“In a way, a DBRE is a specialization of a DBA; it takes the production support aspects of being a DBA and adds a more finely tuned specialization on automation and uptime via prevention and proactive work, rather than reactive and firefighting work.”
Josh (SRE):
“SREs manage the various resources running everything, which can include the database servers, but their depth of knowledge isn’t as deep as that of DBREs, who are the experts on all things database. I would say from my perspective, a DBRE's knowledge goes deeper into the application layer than an SRE’s. I might have some knowledge on database performance, but it's only enough for some context for general troubleshooting. SREs generally wouldn't have deep knowledge on complex queries, replication, etc.”
These are all pretty much in line with my thinking. Using my own experience and these quotes as a guide, I tried to simplify this information into a graphic to represent the separation and overlap you might expect to see between these roles:
These boundaries are definitely not straight lines—some teams will share more responsibility and collaboration around different areas, depending on the company and current projects and priorities. One thing I can say for sure: when possible, you should strive to have some level of understanding of every element in the diagram, even those outside the bounds of your current role. I know a lot more about Redis than I did a year ago, and this has helped me understand and even contribute to incidents in a way I couldn’t have in previous roles. At the same time, I don’t expect SREs to suddenly task me with Redis development or configuration.
I will stress again this may not be representative of your organization; every place is a little different. Sometimes, you might have one person or a small team simply responsible for the entire diagram. At other places, the DBAs and DBREs may have no knowledge of (never mind influence on) some of the items in the upper right. You might have a DBA title, but you may actually do the exact same things in your role as I’m doing in mine. You might have a DBRE title but do a totally different set of tasks in your role. So many factors can influence this, which makes it difficult to represent what you should be doing in either role or as you transition from one to another. (Here are my tips on
how DBAs and DBREs can improve productivity.) I just wanted to share what I’ve experienced (so far) and suggest it’s dynamic and will probably have changed by the time you read this.
