What to do when they are sure it was the database... all the time

It can be tiring to have the database constantly be the Prime Suspect for performance problems.

There’s a right way and a wrong way to handle it.

I’ve had so many variations of this conversation over the years:

Something happened, and we’re pretty sure it was the database. Again.

The wrong way to handle this is to dismiss the concern, OR to just perform health checks without addressing the frequent questioning.

Frequent vibe checks indicate an underlying problem

It can be annoying to be interrupted. Sometimes it feels like everyone is always blaming the database. And sometimes it feels like people simply don’t want to do things themselves.

But usually, there’s an underlying problem where people feel like they can’t tell the health of the database without asking a specialist, and probably having to wait for the answer. People don’t usually like to wait, they want to get on with their day.

Does someone asking, “hey, was something up with the database?” have a way to:

• Review utilization and query runtime for the time in question?
• Check what wait stats were in the time period and compare them to a baseline?
• Check the ​database logs​ for errors or odd messages?

If they have a way to do this, is it easy for them to remember how to do it and access it? Could a custom report or a set of instructions help them run through the process more easily?

Talk to your questioner about what types of tooling, information, or processes could help them get this information themselves, without having to wait.

“Ack! I don’t have time for that!”

These tools or processes may not be things that you can stop and create immediately, and that’s fine.

When having this discussion, think about yourself as a type of “product manager” for working with the database. You aren’t volunteering to do things, and it’s fine to be clear about that. The important thing is to explore and understand your customer’s problem, and why it isn’t easy for them to do this yourself. That can be valuable information on how your team can work with others better, and can be a cause that you can champion (even if you aren’t doing the work yourself) in the future.

It’s also valuable to set expectations clearly. It’s great to tell your coworker that your plate is full, and you may not be able to solve their bigger problem immediately, but that you’d like to learn more about it so that you can share it with your team.

But I’m just a DBA

More and more, seniority in tech roles isn’t purely about coding skills or deep technical knowledge. It’s also about:

• Understanding your customers, their pain points, and why they choose specific tools and processes.
• Advocating for ways to help your customers work better, and including them in relevant conversations so they can advocate for themselves.
• “Leading up” and get time allocated to get work done for your customers– even if you aren’t doing it yourself.

In other words, situations like this are truly opportunities.

Don’t get trapped in thinking that your value is in being the one to manually answer these questions as they come up on an individual basis. There’s an even greater value you can give in helping equip people to answer these questions themselves! Don’t worry– there will always be harder questions that they will come back to you for later.

No matter how hard you try to automate yourself out of a job, in my experience it only helps your career.