I am normally not a fan of all of those awards. I’ve had pay for play offers to get CIO Review Magazine best in service, CEO of the year, Azure Service Provider of the year, etc many years in a row. If I pay enough for the honor, I’ll get it and can even put a press release on the website. I’ve had the offers to be an “Author” on Forbes Publishing – they’ll assign me a ghost writer, and I can order as many copies as I want to give out – and it will only cost me 5-6 figures….

But we found out this year that last year and this year, Clearly Rated has listed us in the Best Of IT Services category because of our NPS.

But this is a fun one. We do pay Clearly Rated, but we pay them before we know the results and we pay them no matter what the results are, we’re paying for the survey process and having it handled by an independent third party with audits and checks. We’ve been paying them for many years now to survey our clients. I want honest, transparent, and actionable feedback from our clients. We ask them how we’re doing, the renewals and low churn speak for themselves, but I have a growth mindset and we can always be just a bit better than we were. So we have them do the surveys, we can’t tweak the results and doctor them up.

And apparently we’re better at taking care of client SQL Server environments than we are at keeping track of awards…

Why We Use ClearlyRated in the First Place

At first 7ish years ago, I had built a SurveyMonkey survey to send to users. How are we doing? Where can we improve? The goal was to get a number score (Clearly rated uses NPS – NPS alone is bad, I think – it gets sentiment but not the why, and not the trends and micro-trends to continually improve service), but to find out where we can improve. You can chalk that up to one part always wanting to be a bit better, and one part being the kind of person who always thinks I’m just one implosion away from a bad moment. I wanted to make sure we were always a good value and earning the renewals, not just presuming on them.

A friend told me about Clearly Rated that they used and they liked that it was arm’s length. The results are the results, but it is scientific, repeatable to survey and you can even see how your team does against each other (in the early days of Straight Path) or how your divisions are doing (today) so you can see if there is training to be done.

We also wanted to solicit feedback. Sure I want the kudos and testimonials – and check out our page from the link above. We get them! But we also ask a loaded question that says even if you are happy, tell us one area we can improve. We then follow-up on those areas that folks identify.

In fact, it was the annual survey a number of years ago where we saw that while we got high marks and clearly folks loved us – we noticed one category was stronger in the “usually” category than the “always” category compared to the rest… Proactive. We ask a series of We are …… A good value/proactive/responsive/etc. And Proactive was looking like a solid B – but the others were in the A to A plus camp. We launched our proactive dashboards, and ultimately decided to make the tool that is our monitoring tool, Skopos, that we are in the midst of rolling out. Because the surveys said we could be just a bit more proactive.

Feedback from clients who seem to mostly like us but are put on the spot to tell us where we can improve is priceless. And when there is a trend – that’s fodder for our annual goals and off-site meeting.

The goal with this process isn’t to someday achieve some “good enough” rating and stop. It’s to set a target and keep working towards it.

What The Numbers Show

Our team apparently earned the Clearly Rated Best of IT Services award in both 2025 and 2026. Our current public profile there shows we have 235 verified client ratings, 4.9 out of 5 stars and we have the 2025 and 2026 best in service award designations on our profile.

Our team is amazing. I’m sure there are many great teams out there – and we’re friends with quite a few of them – but this is a testament to the concern for client service and our values (Trust360, Ownership Mentality, Generosity and Humility) in each member of our team. Our NPS is unheard of in most service industries – 93.5% in 2026, 90% in 2025.

The numbers show that we listen, we care, we learn from them and we work hard at finding the themes and patterns to improve in. We will never have the attitude of “we’ve arrived.”

Winning Twice Means More Than Winning Once

Seeing that we have high scores each year makes me really proud of the team and all they do to work on service delivery and relationship building. The survey responses that speak of us as a partner or part of our clients’ teams speaks volumes about each person on our team and the way they care for our clients.

Seeing that we won two years in a row means we didn’t just have a good or lucky year – it means our team is consistently doing what they need to be. Even if I hammer on the “where can we improve?” responses – I do it because I care about us striving to always get better. And the team doesn’t just put up with it, they listen and work on it.

Winning a sale is great. Having a renewal after a first quarter is great since we don’t keep folks on a cell-phone contract like so many do. But year over year renewals for the long haul combined with surveys painting a similar picture over the years shows that our team is genuinely appreciated and that our focus on relationship, values, and culture first is working. I’m counting on that mattering well into the future, even as AI and automation seek to remove that connection and the values from the equation.

It Does Not Mean We Get Everything Right

I just posted yesterday about 9 ways that managed DBA services can go wrong. And there are way more than 9 ways. Our one detractor score we ever got was still directed squarely at me. I have communication issues. I sometimes err on the side of Ownership Mentality and have picked the wrong hill to die on. I’ve grown, but I still get it wrong. Our team has had to be coached, we’ve dropped balls. Some client relationships weren’t right. We learned about the 3 bad fits I blogged about a few weeks ago through the survey and self-reflection.

But. We’ve heard all of the feedback. I’m sure our clients can tell you while rolling their eyes about the meeting request that Evan, our COO, and I send to hear more about the constructive feedback. We take each piece of feedback and learn from it. We teach the team. We coach. We make sessions at the annual meeting – we optimize to learn.

The Feedback Matters More Than the Badge

Awards are useful external evidence, particularly in a market filled with self-reported claims and a gazillion accolades and headlines available to purchase. But a badge or a headline can’t tell you how to actually run your company better and where to make the tweaks.

It’s the client comments, the patterns, the trends, and the ratings that are tough to read that can promote the change. It’s the relentless follow-up on the feedback received that can give you the ideas to create a Proactive data warehouse and PowerBI reports for folks or finally make the gigantic investment in your own monitoring tool.

We get the hard truths and the incremental improvements from surveys that we’d never get from buying that accolade I can buy 4-6 times a year in my e-mail or signing that deal to become “an author” of my own Forbes book.

Things like:

• Better transitions when a lead DBA leaves and a new one joins (talked about that yesterday)
• Better documentation for the team on our playbook to be consistent in service (Evan is working on that right now)
• Better monthly communications at our monthly client check-ins.
• Clearer escalation paths.
• Paying a bit more attention to hours and engagement sizing from the start.

There is more. And there always will be something to improve. Likewise, with our team, we have our annual all-hands meeting in Boston this year in a few weeks. We ask our clients to be in emergency only mode for a few days with us while we retool, improve and come back stronger and better each year. But we ask the team to break into groups each year and write up issues for our issues list. And the leadership team works hard at engaging on improving those issues all year. We do a great job. But there will always be a thing to improve from a client. There will always be things about our model and how we do business that can be made better for our team. There are certainly moments where the human side of me and the self-doubt side of me would rather just pretend like things are fine and not do the surveys, not read the speaker feedback form after I deliver a session and not do the issues list. But we won’t grow if we don’t.

Don’t get me wrong. The badge is really cool. And to have it two years in a row? I’m excited.

Thank You

As always a big thanks to the clients who take the time to respond each year and not get annoyed at the repeated reminders that the surveys are out there. Thank you to the team who work hard daily to keep our level of service always getting just a bit better. We have one of the most amazing teams out there. Sure they are the folks who are MVPs, authors, bloggers, community tool makers, and folks who taught the MCMs – but they are also people who genuinely care about our clients. And not just because of a feedback score. It shows.

And thanks to the clients who share the tough feedback when we could have done a better job. It’s that feedback and your trust in us to share that with us that helps inspire us to get it right.

Closing: We’ll Try to Pay Better Attention Next Year

If we win this in 2027, we’ll do a better job of noticing it so I can congratulate our team and thank our clients. If we don’t? I’ll tell you we didn’t and tell you what we learned. But either way, we’ll be doing our survey with Clearly Rated next year and learning what the survey shows us next spring and summer.

Some Links

• Our ClearlyRated profile.
• Our Remote SQL Server DBA/ DBA as a Service page.
• Our AboutUs page

The post We Won ClearlyRated’s Best of IT Services Award Two Years in a Row appeared first on SQL Server Consulting - Straight Path Solutions.

Remote DBA services can go wrong because the provider fails, because the client makes it difficult for the service model to work, or because neither side clearly defined the ownership, expectations, and relationship in the first place.

Usually when it goes poorly, everyone involved on both sides is competent and has the best of intentions, but nobody ever really clarified what “DBA as a Service” means.

We’ve been a company for 15 years, since July of 2011, and we’ve been delivering DBA as a Service with a team the way we do today for about 10 of those years. That means we’ve seen versions of all of these… Situations where we’ve taken over a relationship, or given some advice, and even even situations where we could have done better ourselves and learned along the way.

If you’re thinking about moving forward with a Remote DBA firm/Managed DBA services/DBA as a Service firm (insert your favorite phrase here – Fractional DBA as some friends in the industry call it works, too) – here’s a list of some problems worth thinking about before you sign an agreement. With us, or any of our friends in the space.

This post is part of our series about Buying DBA Services. Some thoughts and tips to help you on your journey to buying services from us or our friends in the industry.

1. What happens when nobody knows who actually owns the SQL Server problem?

Any new partner will create some gaps in ownership without great communication. A managed DBA relationship can definitely create friction when who owns what and who does what isn’t clear.

Internal IT, the DBAaaS provider, an outside MSP, application vendors, developers, the cloud provider, storage/network teams, and SaaS application support can all assume someone else is watching. They can all assume they are the ones who should make the change, sometimes unilaterally. Backups, restore testing, storage alerts, Windows patching, SQL patching, vendor escalations, maintenance best practices, performance response, and downtime approval all need clear owners.

When something breaks, “that’s not us” is a failure mode. So is the quieter version where everyone assumes the managed DBA team is covering something they were never scoped to own (or any of the teams are expected to own something they never should have.)

Healthy version: responsibility, accountability, consultation, and information are explicit.

2. What happens when your Remote DBA provider never really learns your environment?

If every ticket feels like starting over… “Which application is this? Who’s the vendor? Why is it configured this way?” and the basics are never moved past, you don’t have an established DBA relationship. You have consultants with a recurring invoice.

Institutional knowledge should accumulate: architecture, business context, which servers are fragile, which vendors require unusual settings, what changes the organization will not tolerate, and the history of prior decisions.

Documentation, a named lead DBA with a regular meeting cadence learning the environment (and then documenting it for the rest of their team), and a team that actually uses ticket history and reads the notes are the difference.

* – This is an area we’ve seen a need for improvement over the years. In the early years I pretty much knew it all – there are IP addresses I still remember for some of our clients who are still clients ten years later – but we are a bigger team, and standardizing documentation, making sure we track the important details and properly work on hand off is a key part of what Evan is doing as we continually mature operationally.

3. Can DBA as a Service become too reactive?

Yes. Admittedly it can happen. The opposite is also scary, and I still think maybe a bit more scary…

A provider can look excellent on response metrics while repeatedly fixing the same underlying condition. Ticket → fix → ticket → fix. The SLA stays green while the real problem never gets addressed. That’s the “Security monitor” thing I always get at when I show my team that old Geico commercial I referenced in an earlier post.

The useful question is whether the team has both the capacity and the incentive to ask “why does this keep happening?” and then do something about it. Purely reactive managed DBA is just expensive break-fix. We’ve taken over from some of the break-fix only services. But as I get at in that post I just linked to, some clients really just want the quick and reactive “fix” and not the solution.

Know what you want here and ask the questions to understand if the approach will match what you need.

4. What happens when you buy too few DBA hours?

Undersizing can make for some awkward conversations without good, regular check-ins from your sales rep or Lead DBA (we don’t have sales reps here, but really – whoever manages your relationship with the provider. For us, it’s your lead DBA.)

When there isn’t regular communication and a clear idea of desires, confusion wins. The client becomes reluctant to use the team. The DBA becomes reluctant to spend hours. Proactive work gets deferred. Technical debt survives. Six months later everyone wonders why nothing meaningful improved.

Providers can contribute to this by underselling to win the deal. A correctly sized service is often cheaper than a cheap service that never has room to do the work. When usage genuinely drops, a good provider should tell you to move down a tier. A model that doesn’t fix someone at a level but allows flexing up and down to save on overage helps, also.

5. What happens when the DBA team gives good advice the client cannot (or will not) act on?

The recommendation is sound. The maintenance window never appears. Restore testing has no resources allocated and the budget excuse comes up. The upgrade keeps sliding to the point a client is open to security risks that impact their compliance. The vendor configuration stays broken because of politics, competing priorities, or a vendor that refuses to change.

Sometimes the provider failed to translate the recommendation into clear business impact, realistic effort, and a next step that accounts for how your company actually works. Sometimes the client truly cannot or will not act. We find with good communication, a compromise and approach to getting towards compliance can happen. Sometimes impasse wins, and that’s a situation that is waiting for a big and bad moment and, I think, ought to be discussed.

DBA as a Service cannot outsource the client’s ability to make decisions or navigate internal reality, but a provider needs to be willing to have the tough conversations and “lead” the client – accepting that not every hill is a hill to die on. On the sales and onboarding calls be honest and open about your “can’t budge” scenarios, and get a sense for how the provider will or will not work around that.

6. What happens when communication is bad?

Technical accuracy is not the same as successful communication. “MAXDOP is wrong” is a simple finding to use here, but insert any other one, phrased without context, and a finding can land as noise. Something the client experiences as urgent can look routine to the DBA. Sales language about “monitoring” can be heard as “a human is watching and will fix everything automatically.” For some shops they mean that for others they literally mean the monitoring, but the humans are watching during certain hours and days.

Ticket updates the provider considers sufficient can be invisible to the people who actually need to know. Expectations always fail first in the “setting” phase – then they can fail in the meeting phase. A lot of the times, the situations I get brought into are almost always on the “failure to set and communicate side.” Turns out humans are humans and communicating well isn’t universal (I struggle with it – there are 2-3 clients over the past 15 years who would tell you all about my failures there.)

Ask your provider how regular updates happen. Is it a “QBR” with a sales and account exec? Is it a monthly meeting with the DBA? Who can you call for escalations? Does someone review tickets and coach their team? Do others join our calls?

7. What happens when emergency and after-hours expectations aren’t clear?

“24×7,” “on-call,” “monitoring,” “15-minute response,” and “emergency support” can describe very different realities and there are a host of other nuances to add to those.

Who notices the problem? Does the client have to initiate? What actually qualifies as P1? Does “response” mean acknowledgment or active troubleshooting? Is remediation included? What happens if the primary person doesn’t answer? What happens after hours?

Ask any provider to walk you through exactly what happens at 2:13 a.m. when production is down. The clarity (or lack of it) is revealing.

I’ll tell you right here – we don’t have a 24×7 NOC watching alerts. It’s worked really well for our 130+ clients who we manage. Many manufacturers with 3 shifts, hospitals, Credit Unions who manage their own online banking with 24/7 up time SLAs, SaaS companies who make their year around Black Friday, and more have seen success with our support model. And we are fine without having that NOC – I personally believe that a DBA shouldn’t be the first tier of support. We are very clear about that on the sales calls. We have an on-call rotation with our full-time DBAs – you call the number and within 15 minutes a DBA is on a call with you.

8. What happens when the lead DBA leaves or the relationship with them breaks?

Even in a team model, most clients form a primary relationship with one person. At Straight Path we believe in “it takes a village”, and most of our clients get to know a lot of the folks on our team. But they still have a Lead DBA. We don’t have a salesperson doing a QBR – we have a Lead DBA in a monthly meeting (some clients are weekly or bi-monthly during active projects and some just need it for their relationship with all that’s going on.) When that person leaves the provider, changes roles, or the working relationship stops clicking and a client is better served by a different lead (for communication styles, skill depths or any number of reasons), context and tribal knowledge can disappear.

A mature provider should have real documentation, shared history, and enough depth that the loss is painful but not catastrophic. Many do not. The client then experiences the service as starting over with someone who doesn’t know them.

If the value of the relationship lives mostly in one human’s head, you still have key-person risk. Ask how they handle the transitions, what lessons they’ve learned over the years with it,

* – We’ve dealt with this ourselves. We have a really good “Sabbatical/Major Leave” transition plan and policy. No one’s sabbatical can occur until they’ve done really thorough handoffs and intros are made and our leadership team watches that handoff. It works amazingly well. But we never really thought to apply that same rigor to the “oh no a DBA is leaving!” – that happens so infrequently, our team just stays, but we learned that this year when a DBA left – a couple clients were not lost, but not handed off as well as they could have been to their amazing new DBA. We’ve worked on that with internal policies and a lot more review with DBA to DBA transitions, even when we’re just shuffling clients around for scheduling.

9. Can a managed DBA provider create too much dependency?

An unhealthy version of retention looks like this: “We can’t leave them because nobody else understands anything.” I think inertia should NEVER be a customer retention policy for a provider – because eventually the cruddy performance or repeat issues will erase their loyalty and there is nothing to keep them. Gatekeeping and knowledge hoarding are, likewise, a terrible retention plan for a DBA as a Service relationship. So is “the contract has an exit penalty…”

If leaving would create an operational crisis solely because knowledge, credentials, architecture decisions, and history lived only in the provider’s heads and they always said “why are you asking that, just let us press those buttons, we got it, ignore us…”, then you’re in for a rude awakening someday…

Healthy relationships document, transfer knowledge, keep access belonging to the client, and make transition possible. Clients should stay because the relationship continues to provide value, not because departure has been made artificially difficult.

Ask if they mentor your team. Ask if it’s a sign of success to see a client downgrade a level because their team took on knowledge. Ask if they’ll tell you when it’s time to hire someone and how they can help you hire and train them. Listen carefully to the answer and push into any answers that make you question the authenticity. This is your environment, after all. And any managed service provider is here as a guest who should be staying because they are so helpful you can’t think of any other scenario than them staying – not because you have a fear of what can break when they leave.

How to avoid these problems before you sign

Can Straight Path have these problems?

Yeah. I’ve highlighted a couple specific areas above with asterisks, but absolutely we can and have. I could come up with examples for most of these where we’ve learned somewhere over the past ten years, or are still learning.

We’re humans running a service business. We have undersized engagements. We have had communication misses. I’ve picked the wrong hills to die on and learned. I’ve been over-protective of team members. We have had relationships where expectations weren’t aligned as cleanly as they should have been. We’re learning and growing, Clearly Rated has named us as Best In Service for IT Providers for the past two years and we build relationships that really last here, so it’s not all bad. But, yeah, there are a few I wish I could take back over the past ten years, and a few clients who I would have helped move on much much sooner because they weren’t a great fit.

We have also had the more ordinary failures: moments where we needed to explain something differently, where a lead relationship wasn’t clicking and we were slow to adjust, or where we didn’t surface a constraint early enough.

The interesting question is not whether a provider has ever experienced these failures. I’d be skeptical of anyone who’s been doing this for years and claims otherwise. The better questions are how they notice, how they course-correct, how clients can escalate, what happens when a lead relationship isn’t working, and what they actually learn when something goes wrong or a client leaves.

That is the conversation worth having.

The post 9 Ways Managed DBA Services can Go Wrong appeared first on SQL Server Consulting - Straight Path Solutions.

Sometimes just buying a bucket of hours makes more sense.

If you already have your SQL Server operations in-hand (good monitoring, a team that responds appropriately, after hours support, and you aren’t just relying on a single DBA who has to bring their laptop and phone on vacation) but you want some advice, tuning help, migration support you just don’t need an ongoing managed relationship.

If part of the problem is you don’t have someone watching, you don’t really own the alerts (or keep seeing the same ones over and over) and your coverage disappears when the DBA is on vacation, or out sick (or quits…) – then you probably need the Remote DBA offering.

One is buying “work” – the other is buying an ongoing relationship and comes with the break glass in case of emergency model already built in.

Short answer up front: Choose the bucket of hours approach when you have that coverage locked in place, you know you are covered day to day, and don’t need an SLA on that team’s response. You want some expertise to mentor, guide, help, or offload some work to a team of experts. Choose a Remote DBA team when you also want that monitoring coverage, a team that knows you and your environment and one that can proactively keep you out of most trouble but quickly respond with a 15-minute SLA when stuff goes bad.

This is part of our series of posts about Buying DBA Services. Trying to give a bit of a transparent look behind the scenes at where it makes sense to partner with a remote DBA shop like ours and where it may not.

What Do SQL Server Consulting Hours Cost?

At Straight Path we keep this pretty straight forward. After years of paying for projects and realizing that costs always change when scope creeps (and it always does) or unknown unknowns become known, I made the decision to keep it simple – we sell a bucket of hours with a pretty simple approach:

• You can buy them in 20 or 40 hour increments.
• A 20 hour bucket costs $7,000. As of 9/1/26, a 40-hour bucket will cost $12,000
• Effective hourly rate of $350/hr or $300/hr.
• Hours are good for a full year from the purchase of the bucket.
• Hours are billed in 15-minute increments
• Our full DBA team is available – the right skillset for the right problem, and that can change based on the needs of a specific project.
• No ongoing monitoring/DBA as a Service infrastructure like daily health checks/alert review/etc.
• SLA is typical next-business day (though we try and beat that).

The bucket of hours approach shines when the need is pretty clear or at least set within some boundaries:

• SQL Server upgrade/migration planning
• Cloud migration projects
• Performance troubleshooting
• Mentoring your existing DBA team
• Reviewing architecture and designs
• Assistance with a project
• Second opinions on a path forward
• Helping your existing DBA team get through a new skillset and learning.
• Azure architecture and CDO services with Buck and team.

Basically – buying a bucket of hours is not inferior to engaging with DBA as a Service. It’s the same team, the same skills, the same values. One is just better for certain situations.

What is a Remote DBA team?

An ongoing relationship where some team of DBAs becomes your DBA team. They take on defined and structured responsibilities usually. Some will bring a monitoring tool they lease or carefully built. Some will rely on a bunch of SQL agent jobs and custom alerts to let them know when you are in trouble and most have an SLA of some sort on when they’ll get back with you on an issue. Some have different SLAs and response times based on plans. Some charge per instance and some per hour.

At Straight Path we include things like:

• Monitoring with SQL Sentry and our proprietary Skopos DB monitoring tool that looks proactively and reactively at your server (We hate chasing the same problems over and over and simply reporting them. I talked about that in this post about clients who are a bad fit.)
• Daily health check e-mail that was human reviewed (without touching your hours for that review)
• Alert review and triage (again, without touching your hours until we connect and work with you)
• An established escalation and on-call process including our 15-minute P1 response.
• The relationship is really about the relationship and we lead each client relationship with a Lead DBA, not a sales person.
• Actual DBA work against the included hours.

You can see a lot more about DBA as a Service pricing on our DBA as a Services page itself or in this post about some common pricing questions.

What’s the Difference Between Remote DBA/Hours?

That table gets to the heart of it for the most part.

Why does a Remote DBA service cost more than the same number of hours?

It depends a bit on the bucket and the level of service. Some other recent posts get into the costs of the service and pricing more but we can look at an example.

A bucket of 40 hours goes for $12,000. If you buy Micro with an annual commitment, it costs $20,000 ($6,000/quarter when bought quarterly instead of annually). So that’s 40 hours for $12,000 or $20,000.

Why would anyone pay that extra $8,000?

Arguably, some companies just shouldn’t. If you need the work and not the relationship and DBA team that can flex up and down and respond? Buy the bucket – a bucket of hours is a bit easier to manage, requires less behind the scenes time that we choose to not bill separately for and we honestly make a bit more margin with the bucket of hours than DBA as a Service to be transparent.

The additional cost isn’t giving you more labor. That additional $667 a month is paying for all of the infrastructure and support built into the DBA as a Service offering. I got into those details a lot more already in the post about the value of hiring full-time vs bringing in a remote dba company on Tuesday. One point from that post worth mentioning here is that those costs are fixed and the bigger the plan you are on for DBA as a Service, the more the cost of those are absorbed into the relationship.

A quarter of Diamond, for instance, lists at $19,000 with 75 hours. 5 hours of overage at Diamond costs $1,250 so the quarter would have cost you $20,250 (though we often will let a client steal a couple or few hours of overage ahead at our Gold and Diamond levels if it’s unusual usage and the next quarter should be back to normal – we like to keep the billing as level as we can unless there is a genuine project need or big emergency). Two 40 hour buckets would get you 80 hours and cost you $24,000. Gold costs $14,000 for 45 hours, again a better option if you need that ongoing support. And clients often switch levels up and down based on forecasted need and we don’t keep people stuck on a contract – each quarter is earned or a client can leave without paying a big exit fee (I don’t love paying for the lawyers when we don’t need to.)

What happens during an emergency under each model?

With a bucket of hours – you have access to the consultants. Clients absolutely do engage with us when the server room is on fire and they need help now – but that’s a conversation at the sales call and if we have the capacity and availability we’ll do our best to support you. Our SLA, though, is still next business day response and if we have the capacity to get you back on the rails and you have hours remaining – we aren’t there for your next emergency in that same way as a DBA as a Service client has.

We can’t really guarantee emergency coverage or even give the bucket of hours clients access to call our on-call line and get the on-call DBA. Our managed DBA services clients are proactively managed with us. This means we know what your environment looks like. For most clients, we are owning and managing your backup and maintenance, we know it’s good because our tools tell us when it’s not. We are able to head off most disasters and we have your info in our systems when you call the on-call number at 2AM and our team on-call that week not only knows you, but knows the playbook you are managed by. We just can’t be as confident with success when you aren’t managed by us.

With DBA as a Service – you get the number, during the day, we may even call you and tell you you have an emergency and we are already in the teams call troubleshooting and we send you a link to join. We’re there for you and we are responding to your alerts and your calls and we’re with you until resolved.

Can you have an internal DBA team and still use a Remote DBA Team?

Absolutely. It happens more often than not. Hybrid patterns can look like:

• Vacation/Illness coverage
• Escalation path for a solo DBA
• A specialist with depth in areas the current DBA doesn’t yet possess
• Project help
• Coverage of alerts and after hours -so your DBA team can get a break on the alerts and after-hours
• A second set of eyes for a solo DBA
• A group of senior DBAs who teach the classes, speak at the conferences, etc for your existing DBA team
• Reducing the risk imposed by a single DBA who is the only one with all the details

More than a handful of our clients or more have existing DBA teams and it’s a great relationship. They learn and grow, we partner and aren’t there to replace them – in fact the way i describe our core value of humility to our team is “Let their team take the credit, we just want the bill paid…” Obviously, that’s partially joking – we pride ourselves on longstanding relationship with clients. That’s why our team has grown from just me steadily to 22 on the team. Clients tend to stay for a long time and we do pretty well on our annual NPS surveys that Clearly Rated runs for us. We’re in it for the success of their DBAs – because we’ve all been the full time DBA when the consultants were brought in – we get it.

Can you start with Remote DBA and move to just hours or vice versa?

Of course. Clients will sometimes move on that journey for various reasons.

A common one is we wind up identifying with our client that there is just an increasing amount of work and they’d be better served by having a DBA team and we can help them find a team, interview them and work to reduce our hours and increase their knowledge and maybe move to a backstop bucket of hours for that training, mentoring, and pinch coverage (we can’t do the ongoing DBA support after hours without monitoring – but we have made exceptions when a company was slowly transitioning to covering on their own..)

Quite often a client who buys a bucket of hours realizes that the findings we keep coming up with are real and they see the cobwebs that they just didn’t know existed until they told us to start looking. And it becomes apparent that they’ve gotten to where they are by one part luck and one part brute force and they want to start doing things right and want a DBA team supporting them without the cost of hiring two DBAs to really cover them and they move over to becoming a DBA as a Service client and we will roll their hours in and make sure they don’t lose them.

We purposefully don’t lock folks into anything here. The bucket expires after a year or when the hours are used. The DBA as a Service is an agreement that renews every quarter if we’ve earned it and someone can leave with a month notice.

How should you decide?

The goal isn’t to solve for the lowest “effective hourly rate” – there’s not that much difference at the end of the year. It’s to find out what problem you are trying to solve with outside help whether it’s Straight Path or another group.

At the end of the day… If you need occasional SQL Server expertise and don’t need that up-time chasing DBA team – maybe you need to buy a bucket of hours. If you want that team watching and supporting, it’s probably DBA as a Service.

And if you picked the “wrong” choice – have no fear with Straight Path at least, we’re a small company, I’m still the sales guy and “final arbiter” of sales-y and relationship decisions (though Evan and the team all agree on the values, it’s why the team keeps taking their 5-year sabbaticals and why some are nearing their second sabbatical already..) if we picked wrong, we’ll figure out the math on moving to the model you actually need. It’s just a lot easier to go into it knowing what you need up front.

Reach out and I’m happy to jump into a chat with you about your needs. I’ll not only tell you which of our options are best for you, I’ll tell you when we’re the wrong fit for you and when you just need to hire a team instead of going with consulting. Here’s some math to help on that decision even.

The post Do You Need a Remote DBA Team or Just SQL Server Consulting Hours? appeared first on SQL Server Consulting - Straight Path Solutions.

Here is how I would do it. I would go find the highest DBA salary survey I could get my hands on, one of the ones that samples a couple dozen people in expensive metros and reports it as a national average, or take the 99th percentile salaries over on Brent’s salary survey. I would take that number and apply a “true cost of an employee” multiplier of 1.8 or 2.0. Then I would add health insurance and payroll taxes and retirement on top of that multiplier, even though the multiplier already had all of them in it. I would assume you replace the person every couple or few years and carry the full replacement cost as an annual line with recruiting costs thrown in. I would sprinkle in a downtime statistic from a survey of Fortune 500 companies and apply it to your environment universally. And I would land somewhere definitely north of $250,000 a year for one DBA, put our price next to it, and let the calculator do the rest.

That math exists. You can find it in about four minutes. Some of it is on hiring vs using a service calculators and webpages out there right now.

I’m not going to play that game here, though… Our first value is Trust360 and everything else we do sits on top of it. If I fudge the one number on this page that you can actually go check, why would you believe anything else I tell you about backups or corruption or whether your availability group is configured correctly?

So here is the honest version, and I will tell you how it ends right now, up front, before you scroll.

On a per-hour basis, hiring a DBA beats us. Every tier we sell. For most salary ranges. It’s not really close on that hourly basis, and it’s even further on our smallest plan, the Micro plan.

Which leaves the actually interesting question, which is why anybody hires us at all. Stick around for that part, because the answer is real and it is not “but you get 24/7 coverage!” This is part of our series of posts about Buying DBA Services. Trying to give a bit of a transparent look behind the scenes at where it makes sense to partner with a remote DBA shop like ours and where it may not.

What assumptions are we using?

I am putting these first, before the numbers, because every single one of them is a dial. Turn any of these and you get a different answer, and anybody who buries their assumptions at the bottom (or leaves them out entirely) is hoping you will not notice which dial they turned.

We did not apply a total compensation multiplier and then add benefits again on top of it. That multiplier already contains health insurance, payroll taxes, retirement, and paid leave. Doing both counts the same dollars twice and it is worth about $30,000 – $40,000 of fake cost.

And we did not put a downtime statistic anywhere in this article. You can find all sorts of surveys saying an hour of downtime costs high six-figures, and those surveys sample big enterprises. Using them to scare a mid-market company running four SQL Servers is a good way to make things seem more expensive.

And for real – check out the Salary Survey Brent Ozar does every year. The data is rich – and there are some outliers perhaps and its anonymous human submitted and he doesn’t edit or massage it so the numbers are raw – I think we could have made this be $125k for the mid level non Jr. DBA and maybe even $165/170k for the Senior DBA – more for superstars. But the numbers work fine either way.

What does a full-time SQL Server DBA actually cost?

Somewhere between about $149,000 and $214,000 a year fully loaded, depending on whether you are hiring a solid mid-level person or a genuine senior specialist. That works out to a multiplier of roughly 1.3 to 1.4 times base salary, not the 1.8 or 2.0 you will see quoted.

A mid-level DBA at $110,000 base

A senior DBA at $160,000 base

Salary is the big number and it stays the big number. The benefits and taxes and recruiting are real and they matter, but they do not double your cost.

How many hours of actual DBA work do you get?

This is where the interesting part is, and it is the number nobody wants to talk about.

Now take out the part of the week that is not database work. Standups, status meetings, the security questionnaire somebody needs filled out, the ticket that turned out to be a network problem, helping with the thing that is not their job but nobody else can do it either, the interview loop for the other open req, annual training, and the twenty minutes every morning that go somewhere nobody can account for.

I’ve been the full-time DBA in the office. And I lived it.. The time goes fast – hallway meetings, getting sucked into a debate, idle chat. I’m also not adding the “extra hours” that many of us DBA types work. The math is rough here – but I’m going somewhere rather generic here.

At 25% non-DBA time you get about 1,380 hours of actual database work in a year. At 35% you get about 1,200. If you think those numbers are too generous or too harsh for your shop, move them, that is fine, the point is that you are not buying 2,080.

So what does an hour of real DBA work cost you?

What does DBA as a Service cost per hour?

Our pricing is on the website and has been since we started. Transparency saves everyone time.

Is it cheaper to hire a DBA or use a managed service?

Per hour, hiring wins, and it is not really that close of a call.

There it is. We are two to four times more expensive per hour for our most expensive hourly (and lowest priced per quarter) plan, and I do not have a clever way to make that table say something else, so I am not going to try.

If you want to stop reading here and go post a job req, I understand, and honestly for some of you that is the right move and we’ll talk more about that in a bit and I already posted a couple weeks ago about clients where we aren’t the best fit.

Why does Micro cost more per hour than Diamond?

I’ve been posting a lot about the “business of business” and I posted last week a bit about how our levels work so I won’t go to deep here, but I’m sure you may be like “uhh why is the Micro, lowest priced quarterly plan the most expensive?!?” Because there is a floor under every engagement we take, and the floor costs us about the same whether you buy 10 hours a quarter or 75.

Here is everything that runs on your environment regardless of which plan you are on, and whether it eats your hours:

Spread that base cost – especially the tooling and monitoring and reviews across 40 hours a year and it is brutal. Spread it across 300 and it nearly disappears. Micro’s $600 an hour is not us charging a premium for expertise at the low end, it is a small number of hours carrying a fixed cost that does not shrink. We don’t sell monitoring only – If we did, we’d some of that fixed price would move out of the plans and the effective hourly number would look quite a bit lower.

Which leads to a recommendation that costs us money: if you are evaluating Micro on an hourly basis, you are evaluating it wrong. Micro exists to buy you monitoring, daily eyes, and a phone number that a full senior heavy team of US based FTE DBAs answers, with a small allotment of hours attached. If what you actually want is hours, and not monitoring, buy a bucket instead. It is $350 an hour and it comes with none of that other stuff, and we will tell you that on the call, because we would rather sell you the right thing.

So why on earth would you hire us?

Because the per-hour number is the wrong question for most of the companies reading this.

Per hour, we lose. Per year, when a company doesn’t have sustained heavy DBA needs, we start to really win.

The employee is more efficient per hour. They are also a fixed cost, and you buy all 1,180 hours whether you need them or not. In fact, when I left the managed services company I was working for trying to build a SQL Server practice with them – I realized we just weren’t going to do it. Most IT MSPs have a harder time justifying a full-time SQL Server DBA services practice. The rates are higher, the size of the team to really support is a bit high and the sales teams aren’t used to selling it. I saw the writing on the wall that we just weren’t growing so I talked to the partners who take a chance on bringing me in. I did the math. I said you don’t use me for a lot of billable hours. So I’m teaching, blogging, marketing, hanging out, and just kind of being around a lot of the time – which means when I do work – my hourly cost is way higher than the math here shows – and my salary was on the lower end. I was ready to be foolish enough and go off on my own and I made a plan where I would leave – they’d make a REALLY good deal on me per hour – and I had one really low rate if I was training or just doing biz dev with them – one higher (but still absurdly low) rate if I was billing. They’d be my anchor client – and get first dibs on my time and for that we’d have a 3, 6 and 9 month guarantee of my availability and their billing. They needed DBA as a Service – I just didn’t know it would be a thing then – and I gave it to them (as a solo person – which means coverage and support is tough when I got busier and had to juggle clients – it’s good to have a team now.)

Where is the actual crossover?

This is the number I would want if I were you, so here it is.

Start with Gold or Diamond and add overage as you go. Depending on the level of resource and the salary range and your details – somewhere between 400-800 hours a year is where things start to cross over to “we’re definitely more expensive”

Translate that to a week and if you consistently need more than about 10 to 15 hours a week of real, hands-on database work, hiring somebody starts to outright win on cost if that’s the only metric you care about.

Note the word “real.” Not 15 hours of somebody being available. Fifteen hours of actual database work. Many of the companies I talk to who are convinced they need a full-time DBA are looking at a backlog, not a regular workload, and those are different things. Clear the backlog in year one or a half a year and then ask yourself what year two looks like.

The four other reasons, which are not about cost

You are buying one person’s skill set when you hire. Nobody is simultaneously an availability groups expert, a replication expert, a query plan person, an Azure architect, and a security specialist. They are strong at two or three of those and learning the rest on your time.

They go on vacation, and then they leave. One DBA is capacity, not coverage. We wrote a whole thing about the perils of being a solo DBA and I will not repeat it here, but the short version is that one is none, two is one.

When things go badly wrong, we flex, and we try not to profit from your bad week. Here is our actual policy – a client can leave us with 30 days’ notice (no cell-phone contracts – why would I want to keep a bad fit client hostage to a contract) and each quarter we evaluate and pick the level that’s right for the hours needed for a client. If someone needs more hours in a quarter once it’s picked they use overage.

In reality, though we like to be flexible and lean into our Generosity value. When it’s just a bit of overage, it makes sense to just make everyone’s life easier and not make the AP folks at our clients hate us and confuse them with “mid-quarter upgrades” – but we also care way more about long-term relationships. Our clients simply stay with us – for a really really long time – like our team – we will often work with a client and maybe upgrade next quarter to the higher level and let them steal hours ahead or, if the need arises soon enough, look the other way and let someone upgrade the current quarter. Saving overage for the smaller one offs.

You will pay more in a quarter where your environment tried to fall over. You are paying for the hours that saved it. And in most years, added up, our clients running anywhere from one instance to scores of them have spent less than a hire would have cost, without giving up a phone number at 2am. So our base is a lot less than the full-time if the hours each week aren’t high – and in a “oh no” flex situation – you may have a more expensive month, but you still work out better by the year.

Sometimes the answer is both, and this is the option most articles skip. Keep your DBA. Put a team behind them.

That last row is worth sitting with. A capable mid level or Junior in-house DBA plus a Silver plan runs about $150,000 – $180,000 all in. Hiring a second DBA for coverage runs whatever the loaded cost for the level you need is. And your existing person gets a peer group in their corner.

When should you hire a full-time DBA instead of outsourcing?

Hire when most of these are true:

• You genuinely have 15 or more hours a week of hands-on database work, sustained, not a one-time backlog
• A real chunk of that work is development, ETL, or data engineering, which we are frankly too expensive to do 40 hours a week with a managed DBA services company
• You want somebody in your daily standups, in every change control meeting and IT team meeting, and/or in the building
• Deep knowledge of your specific application matters more to you than breadth across database specialties
• You can hire well, and you have a plan to keep that person interested after the backlog is gone

Be careful about hiring when:

• The pile of work you are looking at is remediation, not steady state
• You are hiring for coverage instead of capacity, because one person is not coverage
• You cannot answer who mentors them, who reviews their work, or who covers their vacation

And if you read all of that and land on “we should hire,” then hire. Tell us and we can even sell you a bucket of hours good for the year and help you write the req, sit in on the technical interview, and if you want, review their work quarterly so they have somebody senior to argue with. We would rather have that relationship than sell you a plan you should not have bought.

The short version

Per hour, we cost two to four times what an employee costs. That is true and it is on this post in a table above.

Per year, if you don’t have enough to keep a DBA sufficiently busy, we can cost a fraction of a hire and you get monitoring, a team, and coverage when somebody is out that can still flex up for the emergencies.

Above about 10 to 15 hours a week of real,sustained, DBA work, go hire someone, but we can still help provide that coverage and expertise – maybe you can hire a skillset down and we can level them up with you and they stay a bit longer.

The post Hiring a Full-Time DBA vs DBA as a Service appeared first on SQL Server Consulting - Straight Path Solutions.

Our pricing for our Remote DBA service is deliberately pretty simple: one quarterly price, one pool of DBA hours, and a set of services that come with the relationship whether you use every hour or not.

The number itself is the easy part and that doesn’t take a lot of time on calls with potential customers to sort through, but what people usually want to understand is what that number actually buys, what uses their hours, what doesn’t, and what happens when their needs change.

So I’ll try and answer most of those questions here. I don’t mind answering them in the calls also, but I like solutioning and sorting out relationship fit and figuring out the specific challenges on the calls and if we can answer a few questions ahead of time with some posts and videos, that’s more time to talk about the unique challenges.

I talk a bit more about the philosophy (and my extreme dislike for “contact us for pricing details” on a website in the above video.

This post is Part of our Buying DBA Services series: We’re sharing what we’ve learned from inside the managed DBA business over the years to help you understand the costs, tradeoffs, problems, and questions to ask before choosing a provider. The goal is to help you make the right decision, whether that means hiring Straight Path, another DBA company, an internal DBA, or nobody at all.

How much does Straight Path’s DBA as a Service cost?

It’s on the DBA as a Service page but as of today:

• Micro: $6,000/quarter for 10 hours, overage hours are $295/hr.
• Silver: $10,000/quarter for 25 hours, overage hours are $275/hr.
• Gold: $14,000/quarter for 45 hours, overage hours are $265/hr.
• Diamond: $19,000/quarter for 75 hours, overage hours are $250/hr.

Gold and Diamond let you roll forward hours, all levels get the same monitoring and full team relationship, all have access to us after hours. Silver and up start with a Senior DBA owning the relationship, Micros are owned by the amazing DBAs on our support team. But the full team serves all clients – we don’t gatekeep you from the right resource based on your level. More details are on the pricing page.

Why do you charge quarterly instead of monthly?

We actually started pricing monthly way back when – but a few things hit:

1. More overhead – it was a LOT more to track and send invoices.
2. We made more money from overage from clients in some months while other months had hours left over – a lot can change month to month.
3. We wanted more stability in the billing for our client and a bit more time to be proactive.

Monthly is too much churn and too hard to predict. Quarterly can be difficult for some clients but it tends to be the right cycle for natural ebbs and flows in a relationship and normalizes over the 3 months. Some clients wind up on semi-annual and annual plans and for many clients that works well – for some it’s a bit too far out to predict if they don’t have a great annual forecast of work and are going through changes.

Why don’t you price DBA as a Service by the number of SQL Server instances?

Instance count just doesn’t really equate to workload. The age old SQL Server DBA answer to every question is “It depends” – and that really applies to a question like “how busy is one instance?” We have a few clients with a single SQL Server instance who are easily Diamonds forever because of all the important work, help with tuning and SQL Dev work they need, and some that have scores of instances with or without a DBA that can get by on Silver or even Micro. We charge by hours and we let folks change levels quarter by quarter based on needs. This really has worked well.

What is included in the quarterly price?

• Monitoring of their entire estate – daily health checks, alerts as they happen that are watched by our triage team M-F 8AM to 5PM no charges for the tools to be there or the daily health review summary our team looks at and sends or the alert triage. We bill when we get connected.
• A single instance of SQL sentry monitored (more available at our discount – priced with a really steep discount – we aren’t a software reseller – we’re just passing on a discount we get for buying in bulk)
• A staffed on-call team and escalations.
• A lead DBA and access to some of the best of the best DBAs (and access to CDO services, Azure architecture and more with Buck on the team)

What actually uses my included DBA hours?

Whatever you need. I guess you could simply just say, work. We sometimes get calls asking “what about if it’s emergency work? what if it’s proactive? Is it different for reactive? What if it’s reactive but it’s a Tuesday? What if it’s after hours patching work? What if it’s project work vs fix it work?

We don’t play that game here. For two reasons. One because it’s confusing as heck for the customers and a strange service model. The other? Because I don’t want to have to track all of that. If we’re connecting and doing work or talking to you about things or in a meeting – we’re billing in 15 minute increments.

After hours work is still billed in 15-minute increments, but we start the clock at an hour then go to 15 minute increments. So theoretically, if something after hours only took 45 minutes, an hour is deducted from the retainer – but I can’t think of many after hours things that are 30 minute things by the time you get connected, load the ticket, confirm the plan, test the work, etc.

Why does Micro have a higher effective hourly rate than Silver, Gold, or Diamond?

There is a fixed cost to ever DBA as a Service relationship. We don’t do a “monitoring only” plan – but if we did we’d see a bit more normalization between the levels. The things like the monitoring infrastructure and support and dev team and security, our own security and audit compliance, the back office, the team reviewing the alerts and doing the daily health checks that aren’t billing clients for hours. We’re paying for the team to be on-call whether they get a call or not. Mentoring and training. All of these costs are baked into what we do as a company but the fixed client service costs like the alerting and tooling – that has a bit less room to “hide” when a plan like Micro has 10 hours per quarter.

What happens if I don’t use all of my hours?

For the Micro and Silver tiers – we don’t have rollover, but we also don’t like a client losing hours. These plans are really “up to” plans but we do our best to use all of the hours. We have monthly check-in calls and report the hours, we review things, we have a heavy focus on proactive support and catching things before they go bad – and we escalate and keep calling if we aren’t getting feedback. We want to be the most valuable partner that each of our clients work with – and we pride ourselves on winning the best in service award from Clearly Rated, the folks who do our independent surveys. We love it when a client tells us that we’re a partner, not a vendor. We do our best to use the hours.

For Gold and Diamond we have rollover available 10 and 25 hours respectively.

And when a client consistently uses less hours – our leads suggest a downgrade if there are no plans to use them in the future.

What happens if I use more hours than my plan includes?

Every client can purchase overage. We never assume overage either. When a client gets close on hours, their lead DBA sends them a note saying they are burning at a higher rate than their level is at and we ask for which stance they’d like us to take. Allow us to consume up to some number of hours overage at the overage rate (we don’t bill it then – we just get a limit and approval and then bill only what’s used at the end of the quarter.), save some for emergencies, allow only emergency overage, or hold work at the level.

Each level has different overage rates as described above and on the pricing page.

The overage rates are a lot less expensive than the Bucket of Hours rates. This isn’t to punish a bucket of hours client, but it’s to optimize for the relationship – and with an existing DBA as a Service client, we’re often able to better plan and predict and even head off some of the work because we’re really part of their team. I think of it as our clients on DBA as a Service are in some sort of a membership with us. (That said when a bucket of hours gets usage up high – we’ll often offer price breaks and relationship breaks.)

We also will look at an emergency or faster than planned usage as a way to really optimize for the relationship. We try and be creative when it makes sense and let a client upgrade their next quarter and steal ahead (we make a bit less for the overage – but we haven’t profited off of a big emergency – leaving overage for the 10-20 hours above and beyond that happen from time to time not a true increase in workload where the next level just makes sense.)

Why don’t you charge different rates for projects, emergencies, performance tuning, upgrades, patching, and other types of DBA work?

I don’t want a client wondering “shoot which SKU of work is this before I call?!” I want them thinking of us as their partner, in it for them – with them – and if it’s work – it’s just being billed in 15 minute increments. Back when I was on the ambulance as a volunteer – I loved patient care and figuring stuff out and stabilizing a crisis – I really, hated the paperwork. Imagine all of the paperwork and work we’d have to do to have a million different rates based on a flow chart of ideas. Nah… If we’re working with you – we’re billing the retainer in 15 minute increments. Case closed.

(That said after hours support calls are assessed a $500 fee – one and two calls are waived a year for Gold and Diamond) We pride ourselves on getting few calls – the fee is at the right level to be worth it for an emergency, but a bit too high for a “stubbed toe” – the reason we don’t get the calls isn’t the fee – it’s our proactive stance – we like to setup an environment for success ahead of time and focus so hard on prevention.

Can I just buy a bucket of consulting hours instead?

Absolutely.

Buckets of hors list today for $7,000 for 20 hours and we just moved the pricing to $12,000 if a client buys 40 hours at a time. The hours are good until they are exhausted or for a year, whichever comes first. We bill those in 15 minute increments also.

Buckets are great if you don’t want monitoring, if you don’t need alerting, if you don’t need a support team to call – we are getting fewer of our team members access and the work is planned work where we are helping with a defined project, some tuning, a health check and fixes afterwards.

The buckets of hours are NOT for support or break fix after hours or with the 15-minute P1 response (though we still try and help where we can and when we can – the buckets are optimized for project work that is planned and no real DBA support.)

If you just need hours and not support and relationship – just buy the hours.

How do you decide which DBA as a Service level I should start with?

Normally on a call with a potential customer, right about now I’d wet my finger and put it up to the wind and say “it’s a bit of a guessing game.” And, yeah, I really do that far too much (with clean hands!!)

But we kind of “figure it out” on the call. We hear about the pain points, the size of the environment, the size of the team monitoring it, the answers to questions and we take all of the clients we’ve served who feel and look like you and we are able to narrow it down fairly accurately. Onboarding is taken out of those hours also so we talk about the onboarding process – more pain = more time to manage and setup accounts and PAM tools and MFAs and second and tertiary accounts.

But we also tend to optimize for a higher level for the first quarter and we just tell the client if you go with Gold or Diamond based on what it feels like – and we bit off to many hours we’ll give you a one time courtesy rollover – you can rollover all unused hours instead of the 10 or 25 to the next quarter – so we de-risk it and if the hours are used the way we expect (and, usually, they are) we saved them overage, made a little less margin and were able to really help.

But it’s an estimate- and we get it wrong sometimes and that’s why I love running a small company where I’m the sales guy, customer experience officer and founder – we figure it out and make it right. But we’ve been doing this for a long time and we get it right more often than not.

Are your DBAs incentivized to use all of my hours?

They are incentivized to serve you, make you feel protected and cared for, the NPS score of their customers in our annual review, and living to our values (Trust360, Generosity, Humility, Ownership mentality.) So they are incentivized to serve you. That means use the hours we have, not just go into overage because we can and try and blend proactive work to reactive needs and to your budget. If they think more hours are needed they’ll tell you – if the budget is there to go up a level we’ve saved you from overage and keep working, if the budget is a tier lower, we titrate to effect.

We like long-term client relationships and we have lower churn rates of team and customers and I want to keep it that way. We don’t want to bill for solving the same alarm over and over again, we don’t want to actually have you use on-call – and we want to make sure we get what needs to get done and we’ll tell you if your hours are too high or too low – but we’ll respect the budget. It’s absolutely an amazing sign of success when we see a client start at Diamond, move to Gold and then live at Silver because we’ve solved many of their challenges for real – it just means I have to have a few more sales calls when we do it, but so be it.

Can I move between service levels?

Absolutely – we need 30 days’ notice to move levels. We suggest down or upgrades based on what we see and we work with you to pick the right option.

Do I have to sign a long-term contract?

No. Heck no. We once had a client – someone I used to work with and wanted our service – need to wait some time before he could break a contract with another, bigger DBA as a Service client, or pay some exorbitant fee. That reminds me of a scene I hated when I had a summer job. I was working at a beach side store on the east coast – in my small town. And we made fried clams and the owner got after me once because I didn’t properly “fold the bottom of the box up” – basically we were instructed to squeeze the bottom of the box for each size where the boxes were made – it meant the bottom was now I don’t know 1 inch? half an inch higher? And at a point so this mean that maybe 2-3 less fried clams (or scallops or whatever) would fit in the box. I didn’t like it – and I asked what if the customers notice? He pointed to the beach and said “every single day we get how many new people here? and we’re the store here – where are they going to go? and I don’t need repeat business it’s new folks every year.”

A lot of our values and approach to business are informed by crap I’ve had to deal with or don’t like at places. The long term contracts is 100% there as well. Stay because you like us, because we’ve earned your renewal. If we haven’t? Then we don’t deserve your business. We need 30 days’ notice to leave us, too. With no penalty (though you may have to suffer through a call with Evan, our COO, and I to learn lessons and make sure there’s nothing we can do to make it better.

What happens after hours?

We do planned work after hours all the time as described above with the hours. If it’s an emergency you call our on-call number. 888-SQL-DATA and press option 2 and you talk to our answering service who then calls our on-call DBA. They have 5 minutes to answer or they get called again. After the second 5 minutes they call the backup. After 5 minutes there they call Evan or I. The team doesn’t want Evan or I called – usually the backup never has to get called – and then our team member is on with you. Our SLA is to be on a call within 15 minutes of you calling and to be able to be online working with you within an hour at the worst (the team covers for each other and we often will have folks jump in even if not on-call – we all get an e-mail when the on-call number is first called – and Evan, Sheila, and I get a text and we all watch… We sometimes trip over each other to help – but I’d rather it be that way.)

What should I compare when I’m looking at another DBA provider’s price?

Don’t just compare the number.

Ask the questions above. Ask questions like:

• What is included in the base price?
• What consumes hours?
• What doesn’t consume hours?
• Is monitoring included?
• Who actually reviews the monitoring?
• What happens when an alert fires?
• What happens after hours?
• Are emergencies billed differently?
• Is project work billed differently?
• What happens if I don’t use everything?
• Can I change service levels?
• Who actually works on my SQL Servers?
• Who owns the relationship?
• What is explicitly NOT included?
• What happens if I decide to leave?

Evaluate the answers, see how you fit with them and pick the best fit for your needs out of a few providers.

Which Straight Path DBA as a Service level is right for me?

Micro

Micro clients are the one client with two major differences:

1. You have a Support Team DBA as your primary DBA.
2. You have to allow us to use a shared access methodology (which is secure, MFA, etc and we are happy to describe that on the call with you.)

Micro is great if you want the monitoring, the relationship, the ability to flex up. Maybe you have a small environment – and are growing and want someone there with you. Maybe you have a DBA team and want coverage. We’ve thought about renaming this service to Essentials – all of our tools – our full team – we keep the lights on but don’t have a ton of hours to go deep with the proactive.

Silver

You need between 15-25 hours a quarter and have enough complexity to need that Senior DBA relationship and you want us to have time to be proactive and keep ahead of things in your smaller environment.

Gold

This is 45 hours a quarter and has one on-call fee per year waived and rollover available. This is where we start getting to busier environments, a bit more going on and the hours are needed – we’re doing more tuning and performance work , helping do a lot of future proofing. You may or may not have a DBA team. We’ve thought about renaming this level to Professional one day and maybe finding some number of hours that would make Silver and Gold turn into it- The main difference to Silver is the hours but it’s not that huge of a leep -but it saves you $1,500 a quarter in overage if you need to go over.

Diamond

You need 75 or more hours a quarter, we’re doing a lot more work and there is more complexity. We’ve thought about renaming this to “Enterprise” one day. You’d get two on-call fees waived per year.

A bucket of hours

I talked about that above – but really you just need the work, don’t need or want the monitoring, the ongoing reviews and relationships and SLAs – but you’d love the expertise that comes from a team like ours.

The short version

Our DBA as a Service pricing is designed around the amount of DBA work and coverage you actually need, not simply the number of SQL Server instances you own or any other metrics that are really open to interpretation.

You pay one quarterly price. You get a pool of DBA hours plus the monitoring, tooling, coverage, and team infrastructure that comes with the service. We don’t have different rates for different tickets or access to the “good SLA”. It’s just a pool of hours for you to use how you need.

If you need more, we can use overage or move you up. If you consistently need less, we can move you down.

And if you don’t need an ongoing managed relationship at all, we’ll happily sell you a bucket of consulting hours instead.

The goal isn’t to put every company into the biggest DBA as a Service plan we can sell.

It’s to figure out what kind of DBA help you actually need and price the relationship accordingly and grow with you even if as the relationship grows the hours may drift down because of what we’ve accomplished. That’s success.

Still not sure which option fits?

That’s normal. We don’t expect you to diagnose your own DBA workload before talking to us. If you reach out, we’ll ask about your environment, your team, what keeps breaking, what’s coming up, and what you actually want help with. Sometimes we’ll recommend DBA as a Service. Sometimes we’ll recommend a bucket. And sometimes we’ll tell you that what you really need is to hire somebody. Book some time with me or reach out – we don’t have a sales team or sales process – we have a conversation and see if we’re right for each other.

The post How Much Does DBA as a Service Cost? What’s Included, What Uses Hours, and Why We Price It This Way appeared first on SQL Server Consulting - Straight Path Solutions.

We do this every day here at Straight Path using sp_CheckHealth, and we wanted to share it with you.

Here at Straight Path Solutions, we’re big fans of community tools like sp_WhoIsActive, Brent Ozar’s First Responder’s Kit, and Erik Darling’s suite of helpful stored procedures. As database administrators who are constantly looking at new clients and new servers, we wanted one tool we could run the moment we sit down in front of an unfamiliar instance to get the lay of the land and see what needs our attention first. Like many of you, we’ve been using sp_Blitz for years, but we wanted a tool that was more focused on administration-related issues. So, we wrote one.

You can download sp_CheckHealth now from our GitHub repository, along with several other helpful tools for SQL Server.

What does sp_CheckHealth do?

This tool will give you a fast, comprehensive picture of a SQL Server instance. It gathers the kind of information you would otherwise collect by clicking through a dozen dialogs and running a handful of scripts, and it flags potential issues so you can decide what to deal with first. The findings are organized into categories like Recoverability, Security, Availability, Integrity, Reliability, and Performance, and each one comes with details and an action step so you aren’t left guessing about what to do next.

This tool has several modes that present a different set of data, depending on what you want to examine.

• @Mode = 0: only the problematic issues we could find.
• @Mode = 1: instance information only, with one finding per row.
• @Mode = 11: instance information only, returned as a single row. This is handy if you want to collect the same facts from many instances and stack them together, especially if you have a Central Management Server that you can query.
• @Mode = 99: instance information and problematic issues together (the default).

How do I use it?

Execute the script to create sp_CheckHealth in the database of your choice.

Executing it without using parameters runs @Mode = 99 and returns a single result set that includes your instance information followed by any problematic findings, sorted so the most important items are at the top.

Although you can simply execute it as is, there are several optional parameters.

@Help – the default is 0, but setting this to 1 will return some helpful information about sp_CheckHealth and its usage in case you aren’t able to read this web page.

@Mode – see the previous few paragraphs to decide which Mode you want to use.

@DatabaseName – the default results include information for all databases, but use this parameter if you have a specific database that you are reviewing. Using this parameter can greatly reduce the results.

@Override – by default the stored procedure will quit and notify you if you run it on an instance with 50 or more databases, since collecting the history on that many databases can use substantial resources. Use this parameter to override that and run the full check.

@VersionCheck – the default is 0, but setting this to 1 will return the version number and version date of the copy of sp_CheckHealth you are running, and nothing else.

What do the Importance levels mean?

1 – High. This is the stuff that needs your attention, like recoverability gaps, integrity problems, or configuration that is actively working against you. Try to address these when you can.

2 – Medium. This is the stuff that may or may not be intentional, like certain settings, trace flags, or security configuration. Review these findings to make sure they were all intended or expected.

3 – Low. This is stuff that probably isn’t a problem, but you should be aware of it anyway.

What are the requirements to use sp_CheckHealth?

There are two requirements.

Your SQL Server instance should be using SQL Server 2014 or higher. If you are using an earlier version, execution of the stored procedure will skip some checks because some of the DMVs used don’t exist in earlier versions. The results should still be valid and helpful, but you should really consider upgrading to a newer version. Or maybe it errors out for earlier versions, but if it does we can’t help you other than to say that you should plan to migrate to a supported version.

You need to have VIEW SERVER STATE and VIEW ANY DEFINITION permissions. This tool uses several system tables and DMVs to collect information about your SQL Server instance, and these permissions will allow you to read nearly all necessary information. There are some checks that require permission in the sysadmin role, but those are skipped if this permission is not present.

The post Introducing sp_CheckHealth: Check Your Overall SQL Server Health appeared first on SQL Server Consulting - Straight Path Solutions.

Then we look at the date on the report. It’s a year old. And then we look at the environment and not one of the important recommendations has been done. For more than a few of these times, none of them have been done.

And sometimes it could even be our own report from long ago…

That’s the uncomfortable part, and it’s the reason I wanted to write this, life is too short to not be transparent and think about how to solve these things at the same time. If you’re thinking about paying anybody for a SQL Server health check or health assessment or whatever your favorite name for it is (and that includes paying us), the report is not actually the thing you should be evaluating. What happens after the report is the thing.

The short version: health check findings don’t get implemented because a finding without an owner, a date, and a follow-up is just documentation. The report usually didn’t fail. What happened after the report failed, and some of that is on the consultant who wrote it when we don’t make sure you’re ready to go, know what to do, why you should do it, and how to communicate it and verify it.

Why don’t SQL Server health check findings get implemented?

The interesting thing is that this is almost never a knowledge problem. When we come in, the client usually remembers the assessment. They’ll say “oh yeah, we had one of those done, here’s the report if you want it.” Some of them go a step further and ask us to help implement the findings somebody else gave them and provide us the reports and documents and say “here – help us do this stuff….”

So they knew. They were told exactly what needed to change. And a year later nothing changed. There are four reasons we see this over and over, and the last one is the one us consultants don’t like talking about.

Is a recommendation the same thing as an implementation plan?

No, and this is the biggest one.

“You should test your restores.” Great. No duh…. But now go be the person who has to do that, and look at the questions that recommendation leaves sitting on your desk.

The recommendation can be technically perfect and still die right there, because nobody answered the questions that nag the person who has to own it (and their leadership team and change control boards.) And so it becomes one more line on a report that gets filed on a shelf somewhere (you can see a little bit of my messy bookshelf behind me in the video, so I’m not throwing stones – though I keep the really messy shelves off camera.)

A finding without an owner and without a date and without a task is documentation. It is not a plan.

Why do critical findings keep getting pushed to next month?

Because normal life happens, and normal life is relentless.

A performance problem shows up and it takes priority, and honestly it’s funner to work on for most of us DBA types. Somebody needs a report by Thursday. Disk space gets tight. There’s a deployment. Six meetings get scheduled in the same hour and you have to pick at least 3 of them to kind of attend. And the critical recommendation from the assessment becomes “we’ll get to that next month,” and then next quarter, and you already know how that story ends because we’ve all lived it.

We wrote about this in our post on the perils of being a solo DBA, and it’s the same problem. As a company who uses EOS, this falls in the “Capacity” category not the Gets it or Wants it category (IYKYK).

Are DBA Consultants explaining findings in a way the business can act on?

Often, no, and this one is on us as a profession.

We walk into a room and tell an IT Director that MaxDOP is wrong, or the recovery model doesn’t line up with what Veeam is actually doing, or there’s a security configuration problem. All true. All meaningless to somebody who is already holding a list of 47 things from one sysadmin, plus everything coming down from above, plus what clients are pushing in, plus whatever the SOC 2 people asked for this week (we’re nearing the end of our first SOC2 audit – and a question from the auditor takes priority, I get it now!)

If we don’t describe the business impact and answer their questions, it doesn’t get prioritized, and if it doesn’t get prioritized it doesn’t get done.

The frame that works is pretty simple. Here’s what can happen to the business if we don’t do this. Here’s how likely we think that is. Here’s what it takes to fix, in money and time and downtime and reboots. Here’s the risk of making the change, and here’s the risk of doing nothing. And here’s what I’d fix first and why.

Are consultants part of the problem?

Yes, at least partly, and this is the part I don’t think we talk about enough.

If I hand you a brilliant report with 70 findings, take your check, wish you luck, and come back a year later to find you did none of it, I have to at least ask myself whether I actually helped you. Why are all of these still here?

Did I explain it well enough? Did I make the priorities obvious? Did I describe the risk in language your business could use? Did I give you an achievable first step, and did I help you pick the right first thing and then the second thing? Did we establish an owner? Did I follow up with you at all? Was I there to answer questions and encourage you? Did I offer to help you make the changes?

Yes, I took your money and I delivered the report and legally the contract was met if you just bought a health check only (We do sell a SQL Server health check for $997 and we go deep enough with it, but we prefer to sell a bucket of 20 hours, do the health check in the first bunch of hours and have time left over to help actually implement the changes and maybe even follow up a few times if you like.) But why did I deliver it, and why did you pay for it? Was it because you wanted a nice looking PDF, or was it because you wanted to know what was bad and how to fix it?

There’s one more question in there too, which is whether my recommendations were even realistic in your environment. There are two kinds of best practices out there. There are the ones that are right for you and your environment, and there are the ones that are right in a textbook somewhere. Sure, disable the sa account. But if you’re running a vendor app that flat out will not work any other way, is that recommendation helping you, or should we have gotten on a call with your vendor instead?

None of that means the consultant owns your decisions. We can’t. You and your business have to own the decision and you have to act. But we see this enough that it’s good to think through.

What should a SQL Server health assessment actually give you?

These days I care a lot less about handing somebody a big list. A big list is easy. You can get your own big list with all of our free community SP_Check tools – especially now that we’ve released sp_CheckHealth that we use internally to drive a lot of our health checks. You can find the latest free app or vibe coded tool and see what’s not ideal today. What you actually need to walk away knowing is where you’re going to get hurt, what has to be fixed first, what can wait, and who needs to be in the room for each decision. And understand which to apply when and which to hold off on because the ingredients aren’t right for it for you.

Every finding should carry six things:

If the last three are missing, none of us should act surprised when the same findings show up again.

And the practical detail matters just as much as the finding. If we tell you to reformat a drive to a 64K allocation unit and we don’t also say “please don’t do that tomorrow afternoon on the production box with live databases on it,” that’s a failure of the report, not a failure of the reader. What needs downtime, what doesn’t, what’s going to blow away your plan cache and give you an ugly twenty minutes, what’s going to take you offline until you restore if you don’t do the right steps? That belongs in the deliverable so you can work with the approval process and get the stuff approved. That’s why we prefer to stick around and get our hands dirty with the bucket of 20 hours. For the same price as some health assessments, we’ll do the assessment, stretch our hours and make the changes with you, teaching as we go billing in 15-minute increments. We like to see you pay for the findings – and walk away healthy. We can spend the next bucket of hours or do DBA as a Service with you on the funner “next” stuff.

Who owns fixing what a health check finds?

Somebody has to, and it’s worth being clear-eyed about who before you buy anything.

A health check can tell you where you’re exposed. Someone still has to do the work to un-expose you. Sometimes that’s your internal DBA. Sometimes it’s the person on the team who can spell SQL because you don’t have a DBA. Sometimes it’s a consultant, and sometimes it’s a DBA as a Service team working alongside you. Any of those can work. But the “hope it gets fixed and someday we may” approach won’t work most of the time.

What should you ask before you buy a health check from anyone?

This is the part I’d genuinely like you to take with you, whether you buy from us, from one of our friends in the community, or you download a free community tool (our or anyone’s) and run your own.

Don’t just ask what’s in the report. Ask what happens after it.

What Should You Do Next?

If this post has you wondering about the health of your own SQL Server environment, you have a few options.

Want to do it yourself? We’ve released our SQL Server health check tools for free. Start with sp_CheckHealth, and use tools like sp_CheckSecurity to dig deeper into specific areas. Jeff Iannucci and I are also doing a series of free sessions walking through how to assess your own SQL Server environment and what to do with what you find.

Want somebody to help you do the health check? We do SQL Server health checks, too. We’ll help you understand what’s actually dangerous, what should be fixed first, what can wait, and what the path forward should look like. The goal isn’t to hand you a PDF. It’s to leave you knowing what to do next.

Need somebody to actually own this with you? Sometimes a health check isn’t really the problem. You already know there’s technical debt. You don’t have enough DBA capacity to work through it, or you need ongoing monitoring, coverage, and senior DBA help. If that sounds more like your situation, we’ve put together and are continuing to contribute to our Buying DBA Services post series explaining how managed DBA services work, what they cost, when they make sense, when they don’t, and what to ask before you hire any of the great shops providing that service out there.

Do It Yourself → Do your own SQL Server health check. Start with SP_CheckHealth, check out the monthly webinar series Jeff and I are doing on linked in. Intro session recording is here, follow me on LinkedIn to see the links for the next ones.

Get a Health Check → Buy a $997 SQL Server Health Check from us if you want some help and review/documentation.

Get Ongoing DBA Help → Check out our series of posts about the buying DBA services or check out our remote SQL Server dba services – DBA as a Service.

At the end of the day…

If you’re doing it yourself with a free tool, the questions don’t change, they just become an internal conversation. Somebody on your side has to own accountability, or you’ve generated a very accurate list of things that will still be true next year. If you want help with your SQL Server health check, for $997, we can help.

Because at the end of the day, the best assessment in the world doesn’t reduce one single bit of risk if it’s stuck in a PDF.

The post Why SQL Server Health Check Findings Don’t Get Implemented (And What to Ask Before You Buy One) appeared first on SQL Server Consulting - Straight Path Solutions.

There’s a pattern we’ve lived through many times at Straight Path. A client we’ve served for many years gets acquired. Sometimes they are folded into a larger holding company and the client is held forever, sometimes they are raided for their contracts and a few people, sometimes it’s a private equity group making a platform play maybe there’s a strategic benefit. In all cases, eventually – sometimes months – sometimes years – later new leadership comes in for the mandated expense review and contract review. Where can the cuts happen? Where can EBITDA be protected? And they usually find us… We don’t do cell-phone contracts, each quarter is renewed if it’s earned, and if it’s not – we don’t want to force a bad fit. That model really works and it helps us operate within our values even before we’ve sent an invoice. But here? The model can break. For us, sure, we’ll be fine and find new clients, but also for the company we’ve served for a long time. We’re the easy cut. No long term contract, we aren’t even that expensive, so how much value can we really be adding?

Cutting the niche database managed services provider is a pretty easy decision on paper. No severance, no HR talks, not even a contract to really unwind. Surprisingly, we wind up staying more often than not – and for many of those firms we’re still with them as a resource across their entire portfolio of clients because they get the value a team with breadth and depth in SQL Server, Cloud, Databases, Performance, etc that operates in a fractional model. Sometimes we get the cut. A couple of times we’ve gotten the cut and then called back in later…

I’m obviously a bit biased… I run a company that I founded with a team that has grown with me and stays with the company and I think we do a great job. But we also help sometimes with due diligence work FOR these acquirers and we’ve even helped some clients hire the right full-time DBA that replaces us when that is the best answer. So I want to talk about the case for and the case against keeping a company like us…

The Case Against Keeping DBA as a Service Team

There are real reasons to cut a service like ours. Below are a few and if any hit where you are – you probably should cut us or the company like ours.

You have a genuine shared services team with capacity and expertise

Some acquirers – especially the larger vertical software guys have built amazing central platform/database teams that serve their entire portfolio of companies. If that team exists, has senior SQL Server people on it (today SQL server is our platform, though we are in the midst of also becoming a Postgres team, more on that soon) and it can absorb another platform – you absolutely should consolidate that support. You have one standard operating book, one toolset, and you still get one throat to choke – but instead of it being mine it’s the leader of that team. I think the key emphasis here is on genuinely having that. If they are stretched across platforms in your portco, generalists and don’t have the bench of MVPs, authors, trainers, bloggers, etc that your partner has – it could become a case to keeping us around a bit.

The product is being managed down.

Business is business, and I hate to see a product team I loved to work with and build a relationship with have their product be the one chosen to be redundant to the software the new owners already had. But if the buy was for quieting a competitor or moving the MRR to the new product, it’s the decision. Some products get invested in, some get maintained, some get milked along towards sunset and migrations. If the plan for a product is slow wind-down, no new onboardings and sales and customer retention and experience matters a bit less – you may not need as much proactive database support. You don’t need the architectural advice and support, the tuning to keep the clients happy and leaving good reviews or the team catching the P1 before it happens. You still need to test your restores, keep your client’s data secure and stay out of the news with a breach headline – but you maybe can split the tasks among your team or have us wind down to just some hours to support and no actual monitoring and best practices ahead of the curve. We’ll sell you a bucket of hours to help you if you’d like but it makes sense to manage it less if you’re winding it down.

The workload justifies investing in a DBA team.

We tell folks before they sign with us – if you need 40 hours a week of DBA team, we’re too expensive. I have a post coming out in a couple of weeks that does all of that math – and it’s actually closer to 15 hours of consistent steady work – if you are looking at a numbers by the hour game only – we lose there. Sure I believe having one DBA is the same thing as having none and I blogged about that last week. Maybe it’s time to really invest if the work is not getting done and you need a DB developer or DBA there full time. We can help you transition that work to someone and even help you find and train that person. And if you get a team of DBAs who can cover you around the clock for emergencies, the case is closed – you don’t need us in there, and you can save that $20,000 – $72,000 a year you’d spend on us depending on the level.

You’re reducing vendor count for real risk reasons.

This one is a little trickier. We are in the midst of our SOC2 audit and it’s going well, should have our report in hand in a month. And we serve credit unions, banks, healthcare providers, insurance, governments, etc. I think the risk factor isn’t there with us, and we answer plenty of security questionnaires for vendors and haven’t failed one yet. That said – we’re your DBA team so we need certain access, we need certain tools in place, and if we can’t get that for a real risk reason or that’s just the policy from on high – then why pay for a service that you can’t fully utilize.

The Case for Keeping The Service

Your ARR sleeps in your database

Monthly recurring revenue is the lifeblood of the vertical SaaS company world. Your customers have a seemingly endless number of places to put their monthly fees and I could have sworn I wrote a blog post long ago about why Inertia was a terrible customer retention strategy – I can’t find the post or a draft so I’m not sure, I mentioned it in the M&A advice post at least. I still think it’s a poor strategy either way. Customers will leave eventually when that is the strategy. And the renewals go down, the EBITDA slips… Cutting the team who helps keep you in a proactive stance, teaches your team, tunes the environment, and stays ahead of the future corners and has been lobbying the existing team for upgrades and improvements for years is risky.

The math usually doesn’t math the way the report from finance suggests…

A single senior DBA with all-in costs runs somewhere around $190,000 – $220,000 (I just did some review for the post coming in a couple of weeks) or more once benefits, taxes, training,etc is added. And like I already said above, one is none – you have no coverage and if you don’t keep them interested – they’re gone. Not every company, though, always needs the full time DBA hands on keys, so a lot of that salary for many (not all) companies can become an expensive insurance policy. Our team is bringing our own monitoring tool, SQL Sentry, and a team of experts to be your DBA team. For a fraction of the cost – and for many companies at, say, our Gold level, we’re talking about $56,000 per year if they aren’t on an annual arrangement with a slight discount – even if you add in two emergencies and a migration with some overage – you’re easily under $75k for the year. And many clients who are in a niche SaaS industry are getting my with Silver ($40k a year) or Micro ($24k a year if bought by the quarter, $20k if bought by the year) with our team as their team. And all those monitoring tools are run by SaaS companies who want more MRR and longer deals, so we’re saving you from contracts with them since the tooling comes with us.

You’re gonna need that deep DBA bench at somepoint again

Assets get sold, even when the plan was to hold permanently – the economy shifts and stuff moves, merges happen later. When that day comes the new buyers are going to ask those questions about performance, security, compliance, why haven’t you upgraded? Prove out the RPO and RTO the SLA says you offer. Those questions are a lot easier when the DBA team is an extension of your team and, as our reviews suggest, operates like a part of your team. We make those questions get answered with ease and the proof is in the pudding usually.

The spend is already shaped like the way you probably operate

At least when Straight Path is your DBA as a Service provider. Probably most of our friendly competition also. Our model is pretty simple: a relationship based model priced quarterly, renewed quarterly if earned, no long-term exit clause in the contract and it can flex down when spend goes down and flex up when the needs are higher (saving you money from overage.) If integration means there are some aspects of service your central services/platform/DB team can deliver, we can reduce our costs and hours. If you bring in a multi-hat wearing person who can take on some of the work but still need us a backstop or mentor – we reduce and mentor. And you still always get a chance to exit us every 90 days as things change. This seems pretty aligned to a disciplined portfolio management strategy as any outside vendor relationship can get.

Five Questions to Answer Before You Cut the Line Item

1. Who watched the databases at 2AM last month? Who was ready to swing in and fix the issue with a simple phone call and could fix it while the leadership team slept hopefully unaware? Who will watch it after the cut? How quickly will they solve it?
2. What did the last unplanned outage cost? In dollars? In renewals? In reviews? Who fixed it? Who fixes the next one?
3. If we move to the central team, how busy are they? How much attention does this new platform get? How expert are they at the specifics of this environment?
4. Who will push us to make the right decisions based on working with hundreds of customers? Do we know enough about what we don’t know? Do we have the wisdom across a lot of clients to know why one decision isn’t as good as the other? Will the new folks be unbiased or will they prefer a certain direction because of their own incentives?
5. What are we actually saving net of monitoring tools, on-call coverage, the hire we will need and the risk we’re asking to take on?

If the answers and the info above still push towards making the cut – then cut and any great managed services provider worth keeping in your contacts will do a clean knowledge transfer and leave that bridge in-tact and door open. We do every time because tech is small and the industry is small. The relationships often outlast the transactions and we get called in when someone moves on – and we’ve literally been called back when the big company management team switches out the leadership team again and they realize that the databases weren’t getting the love they needed.

The post Should You Keep the Managed DBA Service After Acquisition? Pros and Cons appeared first on SQL Server Consulting - Straight Path Solutions.