3 Times You Should NOT Hire a DBA as a Service Provider

We make money selling DBA as a Service here at Straight Path, but I’d rather not take your money if it isn’t a perfect fit. Being transparent aligns with all of our values, so why not tell folks when a client isn’t an ideal fit.

There are at least three situations where, if you called me and described what you needed, I’d probably tell you not to buy DBA as a Service from us – and all of these are situations where in the early days we said yes and then learned. We’d rather say no now. Actually, I’d probably tell you what I think you should buy instead. I don’t like “no” by itself, our Straight Path Principles suggest that maybe “NO!” isn’t a great answer (unless it’s “should we do an in place upgrade?”)

DBA as a Service is a specific kind of solution to a specific kind of problem. Sometimes you need that. Sometimes you need a different flavor of the DBA services, and there are all sorts of choices out there. And sometimes you really just need to hire a person.

The short answer: DBA as a Service is probably the wrong fit if your organization cannot act on recommendations, if you only want somebody to clear alerts without caring about root cause, or if you really need 30–40 hours a week of dedicated hands-on database work.

The video gets into all of these, but I’ll describe the three situations a bit more here.

1. You’re Paying for Expertise Your Company Can’t Actually Use

The first bad fit is an organization where every recommendation has to travel through six layers of approval, three committees, two architecture review boards, and a partridge in a pear tree before somebody can actually do anything. And even then that’s only if it gets through some pride filters and some curmudgeon client success manager at a software vendor…

• Nobody really owns the decision.
• Everything gets analyzed until nothing happens.
• There’s a term for that: Analysis paralysis.
• I’ve had that job before (and I left for a reason…)

I spent part of my career at a very large, very well-known insurance company where I learned the term firsthand. And to be clear, this isn’t really about company size. We work with large organizations, Circle K and Rawlings Sporting Goods come to mind. Large organizations can be fantastic clients.

The problem is when nobody has the authority, appetite, or ownership to actually improve anything. And that can happen at the smallest of companies – though it does tend to happen just a bit more at the biggest of companies.

You can hire the best DBA team in the world. They can identify the problem correctly. They can show you the risk. They can give you the exact change. They can tell you how they’d test it, how they’d roll it back, how much downtime to expect, and why they think you should do it.

But if all they’re allowed to do is Observe. Document. Wait. …you’re paying for expertise you can’t use.

That’s a terrible way to spend your money.

What should you buy instead?

Maybe you really do need a full-time internal DBA.

Some organizations need someone embedded in the company who understands the political landscape, knows which approvals have to happen, builds relationships over time, attends all of those meetings, and gradually gets things moved through the organization.

That’s a different job from bringing in an outside team that is supposed to help you continuously improve the environment.

And, yes, I joked in the video that maybe you need someone who is really content with things the way they are and waiting for retirement. I’m mostly kidding… Mostly….

The real point is that if your organization cannot consume change at the rate an outside team can recommend it, paying for more recommendations probably isn’t the answer.

Before you hire a DBA service provider, ask yourself: If they tell us what needs to change, can anyone here actually make or allow it to happen?

If the answer is no, solve that problem first.

2. You Really Just Want a Security Monitor

There was an old GEICO commercial I still talk about with our team. Here it is:

Helpful. That’s the analogy I use for the second kind of relationship that isn’t a good fit for us. (And it’s a think I repeat to the team often because I never want us to be a database monitor… Anyone can do that. Vibe-coded apps can do that…)

Some companies don’t really want their managed DBA provider to own anything. That sounds odd, but I mean it. They are just looking for a security monitor in slack hours or to quiet the noise.

They want someone to see an alert quickly, acknowledge it quickly, apply the fastest possible fix, close the ticket, and move on.

Tomorrow, when the same thing happens?

Do it again. And again. And again.

That model absolutely exists.

There are providers with very large teams and operating models built around high-volume alert response. They are very good at it.

If that’s what you need, you should talk to them. But that’s not the relationship we’re trying to build at Straight Path.

Alert clearing and ownership are not the same thing

Our team is full of geeks. I say that lovingly.

They’re authors, bloggers, speakers, longtime SQL Server professionals, and people who get genuinely annoyed when something keeps breaking for the same reason.

If an alert happens, of course we want to fix the immediate problem.

But then we want to know:

• Why did it happen?
• Can we keep it from happening again?
• Is there a configuration issue?
• Is there a capacity problem?
• Is there technical debt we need to eliminate with our client?
• Is this a symptom of something bigger?
• Can we make the environment better so nobody has to wake up for this again next month?

We do not want to be paid forever to chase the same pain.

That doesn’t feel like stewardship to me. It doesn’t meet with any of our values.

And it isn’t how I want our team thinking. It’s not how they want to think anyway..

Fast response is still important

There’s an important distinction here because I don’t want somebody reading this and thinking:

“Straight Path doesn’t like alerts.”

That would be a pretty interesting position for a managed DBA company. We absolutely care about fast response. We just hired Richie Rump to join our developers as we slowly release our Skopos Database Monitoring platform to our clients. We follow ITIL for P1, P2, P3, and we measure that response rate. Do we like alerts? I don ‘t know – but they are critical and we’re on them.,

Our DBA as a Service clients have a 15-minute P1 SLA, and our own full-time DBAs participate in the on-call rotation.

We take the reactive side seriously.

We just prefer this sequence:

Problem → Resolve it → Understand it → Prevent it

instead of:

Problem → Resolve it → Close it → See you tomorrow

There are times when you genuinely just need somebody keeping the lights on.

Maybe your organization is in transition and you’re not ready to address the larger issues yet. Maybe you own the proactive and long-term and fast incident handling is all you want. That’s fine, just recognize what you’re buying.

You may want an alert-response service with fewer Senior DBAs and more helpdesk DBAs around the world more than an ongoing DBA relationship.

3. Sometimes You Don’t Need Managed Services at All

This one probably surprises people more. Sometimes you just need a person.

Not an outside team from a DBA as a Services team. You don’t need a fractional DBA team. You just need a person.

If you have 30 or 40 hours every single week of database work waiting for somebody, DBA as a Service can get expensive compared with simply hiring dedicated capacity.

Maybe you have:

• ETL packages that constantly need work
• Stored procedure development
• Application releases every week
• A giant backlog of database tickets that gets added to faster than it gets emptied
• A role that is one part DBA, one part application developer, one part DevOps engineer, one part developer, and apparently one part who knows.
• Enough day-to-day work to keep one person busy essentially forever

If that describes you, we’re probably too expensive for the job.

We intentionally built our DBA as a Service offering around something different. We want to use a quarterly allotment of hours intelligently.

We want enough room to do proactive work, fix problems, plan ahead, and still preserve capacity for the surprises that inevitably show up.

If what you actually need is somebody sitting in the proverbial chair doing hands-on work 40 hours every week, go hire a contractor or an employee. We can even help you do it.

A managed DBA team can still support that person

This doesn’t mean there’s never a role for us.

We have clients where the model looks more like:

Internal DBA or developer + Straight Path

Maybe we help with architecture. Maybe we mentor the person you hired. Maybe one of our senior DBAs reviews difficult changes. Maybe you bring us in for escalations. Maybe we help interview DBA candidates or think through what the role should actually look like. Maybe we become the person’s backup so they aren’t carrying the entire environment alone.

That can work really well.But don’t buy an expensive team of experts when what you really need is a dedicated pair of hands.

And certainly don’t let a managed-services salesperson convince you otherwise.

So What Are You Actually Trying to Buy?

This is the question I’d ask before comparing DBA providers, reading proposals, or scheduling five demos.

What problem are you actually trying to solve?

Here’s the rough distinction I’d use:

What you really need	Probably look for
A team that knows the environment, responds when things break, proactively reduces risk, improves the environment, advises your team, and provides coverage. Mentors for your team who flex up and down with you.	DBA as a Service / Managed DBA team.
Somebody to watch alerts and rapidly clear incidents	Monitoring / alert-response managed service, more commodity based DBA as a Service Provider – much larger firm.
30–40 hours every week of hands-on work	Full-time DBA, contractor, or staff augmentation
Deep expertise for a specific problem or project	SQL Server consulting engagement, possibly DBA as a Service with a Senior team like Straight Path and our friends at many shops around our size range.
A strong internal DBA who needs coverage, escalation, and broader expertise	DBA as a Service can be great here also with a team who isn’t ever all on vacation at the same time and can teach your team.

None of those is automatically better than the others. And DBA as a Service can slot into many of the situations. The approaches and type/size of the service providers all solve different problems.

I’ve written before about the questions I think you should ask when evaluating a SQL Server managed service provider: team size, coverage, SLAs, proactive work, experience, whether they actually improve the environment, and whether they teach your team instead of gatekeeping knowledge. Those questions matter.

But before you ask any of them, figure out which kind of relationship you need in the first place.

When DBA as a Service Does Make Sense

I’ve spent most of this post telling you when not to buy the thing we sell, so it’s probably fair to explain when I think working with one of the excellent firms our size works really well.

DBA as a Service tends to fit when you want access to a broader SQL Server DBA team without hiring all of that expertise internally.

Maybe you have a good internal DBA but they need backup.

Maybe you have sysadmins managing SQL Server and want experienced DBAs available for the harder work.

Maybe you have nobody dedicated to SQL Server and you need somebody to actually own backups, recoverability, performance, patching, configuration, monitoring, planning, and all the other things that eventually get neglected when everybody is busy.

Maybe you need somebody at 2 AM, but you also want someone thinking at 2 PM about how to prevent the next 2 AM call.

That’s where the model starts making sense.

A Good Provider Should Be Willing to Tell You “No”

There’s probably a larger point here than DBA services themselves. Your journey to a DBA as a Services provider should be one with due diligence and review. I’ve recently shared 7 things to check before you hire a Managed SQL Server DBA service provider and some thoughts on How to Choose a SQL Server Managed Service Provider. Those posts may help you pick the best firm that’s best for your specific situation.

If somebody sells one particular solution and somehow every prospect they meet needs exactly that solution, I’d ask a few more questions. Sometimes we aren’t the right company. Sometimes DBA as a Service isn’t the right service or you need the larger firm.

Sometimes the best thing I can do on a sales call is tell someone, “You shouldn’t buy this from us.”

If you’re trying to figure out which problem you actually have, we’re happy to talk it through. If DBA as a Service makes sense, I’ll tell you. If I think you should hire someone instead, I’ll tell you that too.

That seems like a much better way to start a relationship.