What a DBA team actually deals with

There are many issues a DBA team faces, from servers going down to login access not being requested on time. These are not glamorous problems, but they are the problems that stop everyone else doing their jobs.

In a modern environment you would expect a lot of the smaller tasks to be automated. ‘Automation’ is the buzzword, alongside the ‘war on waste’. The reality is we still lose a lot of time to noise that should not exist.

The hardest part, though, is often not technical at all. It is ‘difficult’ people. They show up across all departments, from staff members right up to managers. There is a real lack of understanding of the pressure a small DBA team is under, and a lack of understanding of the DBA role. It is not only a support role. It is also an engineering and programming role.

SMEs versus bigger enterprises

In SMEs, DBAs can range from operational to development DBAs, and the role is often in a state of flux. Sickness, leave, recruitment gaps and shifting priorities mean you need to be flexible, all the time.

In larger organisations, you often see dedicated DBA teams sitting alongside development teams, sometimes physically in the same space. That naturally improves communication and shared understanding. In an SME environment, you do not have that luxury, so you end up wearing more hats and switching context constantly.

This is where the ‘difficult’ stakeholders create real damage. They do not see the juggling act; they only see their own request. Ironically, as a result, I sometimes have to adopt a firmer stance because, as a manager, I need to shield my team. The wrong interaction at the wrong time can upset a delicate team balance.

Cost pressure and the myth of ‘it’s all just SQL’

At the moment we have massive pressure to cut costs. That often shows up as consolidation and a push towards new tech and new tools, including platforms like Cosmos DB, MongoDB and MySQL, partly because they are cheaper and, in some cases, ‘free’. There is also an assumption that because they have ‘SQL’ in the name, the DBA staff will be able to confidently work with them.

That assumption is wrong.

Each platform has its own nuances, and they are often far from the methodically developed products we know from MSSQL and Oracle. You cannot lift and shift your thinking and expect the same outcomes. It is like assuming someone who understands Cantonese will automatically understand Mandarin. They might pick up parts, but it is not the same language, and you would not want to learn it during a production incident.

The hidden cost is not the licence. The hidden cost is complexity, support burden, automation rework, and the risk of performance or resilience issues when people are forced to learn under pressure.

Automation and monitoring help, but they are not the whole job

Earlier I mentioned automation. We have embraced it, particularly for day-to-day checks, things like SQL Agent logs, Windows Event logs and SQL Server logs. We have built dashboards so we can keep an eye on CPU, UpdateStats, and cycle error logs automatically.

Tools like Redgate Monitor help out a lot as well. It gives you one place to see what is going on across your estate, with configurable alerting and enough detail to diagnose issues quicker. For example, it can flag pressure issues (CPU pressure, blocking, long running queries) and it can alert on failed SQL Agent jobs, among many other alert types.

That said, tools do not replace a good DBA. They cannot replace judgement, experience, or that gut feeling you get when something does not look right, even if the dashboard says everything is “green”. Alerts tell you symptoms. A DBA still has to understand the story behind them.

Performance work is the real value, and it is hard to squeeze in

Automation reduces noise, which matters. But the main focus of a DBA team should be performance and fine-tuning. We do that by looking at query efficiency and index strategy. That work is time-consuming, and it needs proper testing. If shortcuts are taken, especially on realistic testing, massive performance issues can arise after changes are released.

Performance work is also the first thing that gets squeezed when operational noise and meetings take over.

Staffing levels and ‘crisis learning’

Staffing levels create stress and affect the balance of the DBA team. We have someone leaving soon and, because of the current merger, the role is not being filled. That person’s expertise is lost and the team has to compensate.

Other staff members then have to learn new technology, which can be good. Most of the time it is. But when it happens in a crisis, it creates a knowledge deficit. It becomes ‘crisis learning’, where people know enough to keep things moving, but not enough to do it safely and consistently.

In a mixed environment, tasks that were routine in MSSQL become different. Reindexing and performance scripts behave differently. Backup and restore can be different. A lot of companies have a single backup and restore policy. Ours is to backup and restore every database, and we have automation built around an MSSQL environment. Now that we are working across various flavours of SQL, the problem is more complex. Our automation tools are no longer fit for purpose and need reinventing, which diverts time away from analysing performance issues and improving stability.

The DBA role is broader than many people think

A DBA cares about change control. With that comes more than just SQL. In reality, a DBA often needs programming skills (for example C#) to build and maintain tooling that runs stored procedures across environments, creates logins from a front-end tool, takes backups, and provides change control accounts for release managers.

DBAs also end up acting as security specialists and high-level decision makers. We are involved in releasing jobs, running SOC controls, dealing with permissions and audit, and being the last line of defence when something sensitive is about to go live.

We are often treated like jack of all trades, master of none. The truth is we are expected to be masters of reliability in an environment that keeps changing underneath us.

The shift to ‘DevOps style’ without removing the ops load

Lately it has become harder to stay motivated because the team has shifted from being fully operational DBAs to more of a DevOps style team, but we are still doing the operational role at the same time.

That makes it hard to maintain focus. I do not think upper management fully grasps this. On paper the changes look good for figures, but not necessarily for the people doing the work. It also makes it hard to focus on the end game, or even know what the end game is. Large enterprises often plan over a two-year horizon with a roadmap. In the company I work for now, I have never seen a roadmap and things change daily.

That drives communication issues and missed expectations. When a company grows fast, it is easy to miss what is going on in managers’ heads. They have their own objectives, and nothing is really set out clearly for the teams. Deadlines move, priorities change, and it becomes hard to manage your own team because you cannot plan properly.

Meetings are eroding operational time

One thing that needs to change is the amount of meetings we have. It severely erodes time set aside for day-to-day operational work.

We work in sprints now. Sprints can be good because you know what you need to do. But when you combine two-week sprints with constant meetings, it is sometimes hard to finish what you are working on.

Is it really viable to have a meeting for performance issues, a 30-minute stand-up, a retro, sprint planning, refinements, plus other meetings on top, and still expect meaningful delivery? It is hard to focus when your day is chopped into small pieces.

We need to tailor the methodology so we are not having meetings for meetings’ sake, but because there is a real issue to cover and a real decision to make.

Knock-on effects: patching, prevention, and personal development

The knock-on effect is that it leaves little time to improve infrastructure, patch the database systems, and do performance code reviews with developers. That is the work that stops incidents before they happen.

It also reduces self-improvement. Learning and development ends up pushed outside working hours, which destroys work life balance. Add a US office, late-night calls, and out-of-hours support, and it becomes almost impossible to advance technical ability in a healthy way.

Where AI fits (without pretending it fixes everything)

AI is not the solution to any of the problems above. If priorities are unclear and intake is chaotic, AI will not fix that.

Where it can help is the same place automation and monitoring help: reducing waste.

• Summarising incidents and pulling together timelines from logs and alerts
• Drafting post-incident write-ups and updating runbooks
• Helping enforce request quality (for example access requests missing key details)
• Turning meeting notes into actions and owners so fewer meetings are needed
• Helping with a first-pass review of scripts for obvious risk patterns, before a human review

It should never be a replacement for judgement, testing, or ownership. It should be used to remove repeat work and reduce interruptions.

Closing thought

The DBA function is being pulled in multiple directions at once: cost cutting, platform change, DevOps process, operational responsibility, security expectations, and a growing estate. The risk is not that the team cannot cope. The risk is that the organisation normalises constant overload and then acts surprised when stability suffers.

If the business wants reliability, it needs fewer interruptions, clearer boundaries, and time protected for the preventative work that keeps production healthy.

Note: I originally wrote an earlier version of this article for The Stack some time ago. Since then, the day-to-day reality for DBA teams has shifted further, especially with the rise of AI tooling, cost pressure, and the move towards DevOps ways of working. This is an updated version for today.