With that being said, we at Straight Path pride ourselves on proactivity and helping customers to determine what they might need. So, as you may have guessed by the title, this is a blog post about PostgreSQL and some things I’ve learned about it and why I never want to stop being a beginner.

If you’re new to us, Straight Path is a SQL and Database consulting firm started by our CEO Mike Walsh. We’re now at 22 employees and we have backgrounds in performance tuning, migration work, security, and just general DBA knowledge spread out across our Senior and Support teams. There isn’t much we can’t handle as an organization. Our new CDO, Buck Woody, in the spirit of proactivity has seen the writing on the wall as well and knows that our next logical step was Postgres since it’s getting more popular than ever. DBAs and organizations around the world are turning to Postgres for its customization, its easy licensing, and resource management.

I’ve built my career in Microsoft but my OS of choice for my personal projects is Pop!_OS, which is based on Ubuntu and is part of the Free and Open Source Software (FOSS) project. I learned about Linux and the different operating systems built around it when I was fresh out of high school, through my uncle who had been using Linux almost since its inception. I was amazed that so many humans across the world could come together on a project like this and that Linux was responsible for so many things in our lives. Now it’s on billions of devices and runs critical infrastructure that we depend on. I’m saying all of this to emphasize that it’s my passion for being a beginner that got me into Linux in the first place, and that same passion brought me to being a DBA, and now it’s helping me to learn Postgres.

As the title suggests, I didn’t set out to be a DBA, I originally went to school for programming. That job I mentioned earlier hired me partially for my ability to read code. My boss at the time assumed that if I could read C# then I must have been able to read whatever language the company’s software was written in and that would help me in my support role. He wasn’t totally wrong because that light programming background allowed me to talk with the developers and try to understand what we were building. It helped me make relationships that I still maintain today and that ability to be a beginner let me ask questions. I asked questions about everything because it’s how I soak up information. Asking those questions eventually got me pointed to the DBA team because I wanted to know why something wasn’t working, and development eventually pointed the finger at the DBAs. As we all know, DBA does stand for “Default Blame Accepter”.

I started working closely with them and learning anything and everything I could. Eventually that company was going under and I needed to find new work and I found Straight Path. I wanted to take the DBA knowledge I had to the next level because I wanted to be a beginner somewhere else and before I knew it, I was. I was learning the ropes of SQL Agent, jobs and maintenance plans, users and access, and how to troubleshoot issues. Fast forward 5 years and I’ve grown into my role as a DBA where I maintain a list of my own clients and I assist our Senior team with their clients where I can. I focus on proactive work and maintaining a well performing environment while also looking for opportunities to enhance security. The world is only getting less secure these days, and I started all this by being a beginner at something.  

Here I am now, relearning a lot of those same principles but in a new environment with new challenges and new goals. Postgres is a great tool and even though it can do so much for your environment and your workflows, it may or may not be the right tool for your needs.

Postgres is also considered FOSS, and it’s maintained by a dedicated group of people around the world and provided for free in most cases. That philosophy is also part of what brought me to learning it and wanting to use it, as it was like getting to learn about Linux with my uncle all over again.

So, this is a roundabout way of saying that you shouldn’t ever stop being a beginner at something. I took my passion for learning and started with Windows 98 as a kid, then in my teens learned about Linux, then as an adult I found my career with Microsoft software, and now we’re going back to Linux to build out this Postgres plan. More on that to come!

The post The accidental DBA is learning PostgreSQL (and why you should never stop being a beginner) appeared first on SQL Server Consulting - Straight Path Solutions.

Those couple of events piqued my interest so a few months ago I dipped my toes into the Postgres pool.  I started this adventure looking for ways to apply my 20+ years in SQL Server to Postgres so that I can start to help people who are also new to the platform.  One of the very first things I learned about in SQL Server was backups, so I thought it would be fitting to start there with Postgres.

Most of the readers of this post likely know how SQL Server backups work.  You can create a backup of an individual database with a full backup, a differential backup, and a log backup.  You can then use those backup files to restore the database onto the same server or a different server.

With Postgres, there are two categories of backups: a logical backup, and a physical backup.  The logical backup is essentially an export of one or more objects in the database to a file.  The contents of that file could have anything from the scripts to create the objects to the insert statements to reload the data into a table.  But that is all you can really do with a logical backup – create a copy of something in a database and restore it somewhere else.  Useful for certain tasks, but this cannot be used for other administrative tasks like point in time recovery or building physical standby replicas.

A physical backup is where you would start if you needed to perform a point in time restore of a database.  Comparing this to SQL Server this is where you’d restore a full backup, then maybe a diff backup, and then roll log backups until you get to your desired end time. 

One of the big differences between SQL backups and physical Postgres backups is with SQL Server you backup one database; with a physical Postgres backup, you capture the entire Postgres cluster.  One of the reasons for this is that all the databases on the Postgres cluster share the same Write-Ahead Log (WAL) file. Because all databases share the WAL file, everything on the cluster is needed for Postgres to guarantee a database is transactionally consistent.  If there were objects missing from the cluster, it could cause failures while transactions are being replayed from the WAL file backups.

This was a big difference for me when comparing SQL Server and Postgres. With SQL Server I only need to worry about a couple database files and if there is space on the server, but with Postgres there is so much more to take into consideration when preparing to do a point in time restore of a database. 

Looking forward to learning more about the differences between the two platforms and if there are any similarities.

The post Backup a second… this isn’t a SQL Server post? My journey into PostgreSQL backups appeared first on SQL Server Consulting - Straight Path Solutions.

No client asked us to do this

That’s the first thing I want people to know. Nobody made us. We’ve been doing this since 2011 and we’ve passed plenty of vendor questionnaires without a SOC report. Maybe the desire to do a couple less vendor questionnaires motivated me, but then I learned that we’ll still get them – but I also learned that our managed service provider for IT and MS365 and security will also fill those out for me. So that’s still a win.

When you hire us, you’re handing us the keys to the kingdom. Our DBAs get privileged access to SQL Servers that hold patient records, member accounts, customer orders, payroll (the stuff that keeps your business running and keeps people’s lives in order). We help clients get through audits and security reviews all the time. It felt a little hypocritical to keep asking you to trust our answers when we’d never had anyone outside the company check them and keep watching.

What we actually did

We’re a 22-person company. Hiring a full-time CISO didn’t make sense for our size, and the “buy a compliance platform and click through the checklist” route didn’t give me what I wanted, which was someone who knew our business telling me where we were weak. I don’t want a rubber stamp – this was not a cheap expense – and it is a new ongoing line item – the managed security services and the annual audit we’ll have to keep our SOC2 Type II up once we (hopefully) achieve that in 6 months is an expense. The extra time to do some things, the process, the forced patching reboots. It’s all a cost – but it’s worth it.

So we leaned on Mainstay Technologies, who already run our managed IT and security monitoring. Erin Mealey guided the SOC 2 work start to finish, and internally Evan Corbett (our COO) drove the follow-through while Buck Woody brought a lot of hard-won data security and incident response experience from his roles at Microsoft for the past nearly 20 years.

The work itself was a lot of turning things we already did into things we could prove we do: documenting controls, formalizing policies, running every vendor through the same review, security training with evidence behind it, and testing our response plans. We also pulled our monitoring platform, Skopos, and the software we write into scope, because that’s part of how we serve clients and leaving it out would have made the report look tidier than reality.

I expected more misery than we got. The part I figured would be pure box-checking was the disaster tabletop exercises. It wasn’t. Walking through those scenarios surfaced real risks, and we changed some of our approaches and policies because of them. Turns out we had some homework. I’d rather find that out in a conference room than at 2 a.m. on a client’s server.

What a SOC 2 Type I actually is

SOC 2 is an examination framework from the AICPA. An independent CPA firm looks at a company’s description of its system and its controls against a set of criteria. We were examined against the Security criteria, which is the required baseline for every SOC 2.

A Type I is a snapshot only. It says that on a specific date, our controls were in place and suitably designed to meet those criteria.

I spent years as a firefighter and EMT, so here’s how I think about it. A Type I is the inspector walking the building and confirming the smoke detectors are installed, wired correctly, and in the right rooms. A Type II is the inspector coming back and checking the logs to see that they were tested every month and actually went off when there was smoke, and the folks followed the evacuation plan months later.

What it doesn’t mean

This is the part I care about most, because transparency matters, it’s the whole point behind the Buying DBA Services guide posts I’ve been sharing. Don’t let our “SOC2 Achieved!” woo you into letting your guard down. Even when we hopefully pass our Type II audit.

• It isn’t a certification. There’s no such thing as being “SOC 2 certified,” even though you’ll see vendors say it everywhere. It’s an attestation report from a CPA firm. We’ll try hard not to call it a certification, and if you catch us doing it, tell us.
• It doesn’t prove our controls worked over time. That’s what Type II is for, and we’re not there yet.
• It doesn’t mean nothing bad can happen. No report eliminates risk. Anyone who tells you otherwise is selling something.
• It doesn’t cover your servers. The report is about how Straight Path runs. We don’t host your data in our environment. The security of your SQL Servers is still a shared job, and the report even lists things clients are expected to do on their side (auditors call these complementary user entity controls, apparently). We’ll help you with those, but they’re yours. We think the time is right for you to have a PAM tool, as much as the DBA in me cringes typing it, but that’s your decision and a CUEC suggests it – we can tell you how others have done it but this is up to your security team.
• It doesn’t replace your due diligence. It gives you better evidence to work with. You should still ask us hard questions, ask our competitors hard questions, get to know the team, and decide if we’re the right fit.
• It doesn’t mean we changed who we are. We’re still the same bunch of SQL Server geeks. We just have more evidence behind the promise and more documentation, process and checkboxes for the team to follow behind the scenes.

Why it’s still worth it

The SOC 2 (or ISO27001) journey can absolutely be an expensive paperwork exercise that makes a company look secure without making it more secure. I’ve seen that happen.

What made it worth it for us came from a few places:

We found our unknown unknowns. We already had solid basics in place (MFA, background checks, managed devices, active monitoring, phishing tests, perimeter security, see something say something policies, etc.). The value was in the questions we didn’t know to ask ourselves, and the tabletop drills were the best example. Or pushing the same questions and process on our own vendors was a good takeaway – rigidity up and down.

The team’s defaults changed. I’ve watched people make more secure-by-default decisions without anyone prompting them. This team was already mature and security already mattered here, but now I can see it in how everyday choices get made.

Rules for everyone make life easier. When we were five people, a lot of how we worked lived in my head and a couple of other heads. Having clear policies that apply to everyone, me included, has made things simpler than the early days.

Your vendor reviews get easier. If you’re a credit union, you’re expected to do real due diligence on third-party providers and your examiners will ask about it. If you’re in healthcare, you’re asking vendors how they protect PHI. Now we can hand you independent evidence instead of a well-written questionnaire answer alone.

The monitoring already proved itself once. Before the formal SOC 2 work even started, some activity on my laptop tripped an automated response falsely. My laptop got isolated, my account got locked, and Mainstay’s security team called me. It turned out to be harmless. I was annoyed for about an hour, and then really glad, because that’s exactly what I want to happen when something looks wrong.

Why we’re already in the Type II phase

A Type I tells you we designed things well on one day. That’s a real milestone, but it’s a starting line. The question anyone serious about vendor risk will ask next is “did you keep doing it?” Even “are you going to keep doing it diligently forever?”

Yeah we are –> Our six-month Type II observation period with Linford is now underway or about to be (not officially sure how it works – but it’s next and we are waiting 6 months to have enough of a period to catch us doing something wrong, and move it to 2027 so we can go annual after that.) During that window we have to operate the controls we described, keep the evidence, and then let the auditors test random samples across the whole period. If a control slips, the report will say so, we can’t do anything about it. That’s the point of it.

Why annual audits are in our budget

This wasn’t a one-time project, and we’ve budgeted it that way. After the Type II, we plan to be examined every year.

A few reasons:

1. Reports age. A report that covers a period that ended a year ago tells you less and less every month. Auditors themselves recommend producing them annually so there’s no gap between reporting periods.
2. Your reviews are annual. Most of our regulated clients re-review their vendors every year. We should have something current to hand them.
3. Discipline decays without an outside deadline. I know myself alllllll too well. Good habits hold up a lot better when someone independent is coming back to check. Outside accountability helps. Plus it makes the process the bad guy, not me with all our process and procedures and security.
4. It matches how we already do business. We don’t lock clients into long-term contracts, because we think we should have to earn your business every quarter. It would be a little strange to then ask you to trust a snapshot from years ago.

It’s a line item now, like insurance and training. I’m okay with that.

What this means if you work with us (or are thinking about it)

If you’re a client and your compliance team wants to see the report, reach out to us and we’ll get it to you, you’ll see it on your next vendor questionnaire round if you are one of the many who send the links to them. If you’re evaluating us, ask for it, and ask us anything else too. What we train on, what happens when something goes wrong, what our policies actually say. Those are fair questions, and you should ask them of every vendor who touches your data.

We really care about the data we look after. Behind every row in those tables are people, families, customers, and livelihoods. This report is one piece of evidence that we mean it. The rest we’ll keep earning the same way we always have – earning the next renewal by proving ourselves to be a part of your team, not just another vendor.

Have a SQL Server environment you want an honest conversation about? Let’s talk.

The post We Finished SOC 2 Type I (What this is and isn’t) appeared first on SQL Server Consulting - Straight Path Solutions.

I want to do something a little unorthodox here, I’m going to list a few firms I’d actually consider if we weren’t in the picture (or our Remote DBA services weren’t right for you). These are companies I respect. Some of the founders are friends. We’ve referred work back and forth over the years with a few of the firms.

I’m not ranking them. And I’m deliberately not putting Straight Path on this list.

I also left out the big national and global providers. Those firms generally serve a different part of the market than the specialist shops I’m talking about here. If you’re looking for a large enterprise provider, global teams, or a broader outsourcing relationship, some of them may absolutely belong in your search. That’s just not the comparison I’m making in this article.

Here’s my short list. I may be missing a firm that I know and respect, wasn’t trying to be exhaustive but go with the ones that come to mind right now, and I left the solo DBA shops or solo DBA plus one jr. backup out for this comparison.

Sero Group Joe Webb’s company. Smaller team. Values-first and trust-first. Joe has been in the SQL Server community a long time and runs the firm the way a lot of us wish more companies were run. They take compliance seriously (including going on the SOC 2 journey). We’re finishing up our own SOC 2 process right now with our draft report in hand waiting for the final, so I’ve been talking to Joe a bit about his journey. He does it well, and I trust him and his team even without their SOC 2 report. If you want a high-touch specialist shop, Sero is worth a conversation. Joe is one of my favorite people in the SQL Server community, too.

Procure SQL I know and trust the founder and a bunch of the people on their team. Not the smallest team on this list, but not as large a team as Fortified, SQL Watchmen or us. They lean a little more into the broader data platform side (architecture, integration, reporting, analytics) than pure operational DBA work based on what they put on their site first, but they have excellent DBAs and can absolutely do managed DBA services. If your needs sit closer to the development and data platform side of the house, they’re a strong option.

Dallas DBAs Smaller firm. Generally sits at a lower price point than most of the others on this list. Solid coverage and a practical SQL Server focus. We’ve sent some work to them and they’ve sent work to us. Their model is often a good fit when what you really need is lighter fractional coverage with a good, smaller, mid-level team, or a solid emergency backup.

SQLWatchmen Austin-based. Pure SQL Server focus. Founder-led. US-based team. They’ve been doing remote DBA work for a long time and keep the model relatively simple. Another solid specialist option if you want a focused SQL Server shop.

Fortified Data A bit larger than the others on this list. Multi-platform, and they’ve built a commercial monitoring software/product side (Fortified WISdom) in addition to services that they sell, and they have more of an enterprise-oriented feel than some of the smaller specialist shops here. If you need broader database platform coverage or getting into multi-platform support beyond just SQL Server and PostgreSQL that we cover, or a larger operational model, I’d put them on the list of companies to talk to.

As with any provider (including us), I’d make sure you understand the contract terms, service levels, what’s included, how changes to the relationship work and changes between levels work, and what happens if you eventually need to leave. Check out all of the posts with the buying DBA services tag – you can think of questions to ask any of us and get some thoughts on pricing, fit and what to look for in a firm. Next week, I’ll talk about the question we sometimes hear, “Can our MSP be our DBA team? Should they?” It depends and I’ll talk more about it. Then after that one I’ll be putting all of these posts in this tag into a guide for folks to read and give a few checklists. Subscribe to the newsletter to keep up.

How I’d Think About the Short List

There’s plenty of overlap between these companies and even our own, so don’t treat this as a ranking or assume one sentence captures everything a company does. But if I were starting the conversations today, this is roughly how I’d think about them:

• Want a smaller, high-touch specialist relationship with a smaller bench but good experience and compliance chops and one who also works with financial institutions like we do? Talk to Sero Group.
• Need broader data platform and development capabilities or architecture as a service and some help with PowerBI and Fabric resources directly on the team? Talk to Procure SQL.
• Looking for lighter fractional coverage, more keep the lights on support, or more price sensitivity? Talk to Dallas DBAs.
• Want a focused SQL Server specialist model? Talk to SQLWatchmen.
• Need broader database platforms or a larger operational model? Talk to Fortified Data.

Services change. Teams change. Pricing changes. Talk to them and ask questions rather than treating any of this as final answers.

What About Pricing?

Most of these firms don’t publish full pricing the way we do, so you’ll need to fill out quote requests, maybe talk to them to get current numbers and understand what is actually included. Dallas DBAs has historically been one of the more transparent on that front.

And frankly, don’t compare these companies on the quoted price alone.

Ask what the price buys. Does it include monitoring? Who responds to alerts? What happens after hours? Do you get a named DBA? How much actual DBA time is included? What costs extra? Are projects handled differently? What’s the contract commitment? What happens when you need more or less help? What’s the true SLA?

Two companies can both call something “DBA as a Service” or “Remote DBA” and be selling pretty different relationships.

We’ve written quite a bit about those questions elsewhere (the pricing post, the problems post, the first 90 days post, the FTE vs DBA as a Service post) because I think they matter more than trying to reduce every provider to an hourly rate.

Why Am I Publishing a List of Our Competitors?

Because if you’re seriously considering DBA as a Service, you should probably talk to more than one provider and I’d rather tell you who I respect than pretend we’re the only company capable of doing this work well.

If after looking at these options you still think Straight Path is the best fit, we’re happy to talk. If we aren’t? I get it, talk to those shops, you can’t go wrong.

The goal here is the same goal I’ve tried to keep across this whole series. The bad-fit post. The problems post. The full-time DBA vs DBA as a Service post. The first 90 days post. All of it.

Your SQL Server environment should end up with the right team. Not necessarily always our team.

The post Who Would I Use for DBA as a Service If Straight Path Wasn’t an Option? appeared first on SQL Server Consulting - Straight Path Solutions.

But while the technical expertise is important, it’s the white-glove part that really provides our value. We learn what we can about our client’s environments, how they work, and where they need us to help. In some cases, we are their only data and database professionals. We handle everything from performance to HADR. In other cases, we are the specialists that handle the calls their database professionals make. We’ve added Microsoft Azure Architect services, as well as a Data Architect level of services in an advisement role as well – always with a focus on enablement, not just advising. The real value is caring about what happens at the client, and taking an ownership mentality to help them succeed. We’re extremely proud and very jealous about guarding those systems and providing the highest level of service we can.

As part of that understanding of our customers, we’ve heard loud and clear that many are planning to migrate to PostgreSQL. Its powerful engine, flexible query languages, and extension architecture allows it to do just about anything they need in their data estate. It does not have the same licensing costs (if any) that Microsoft’s platform requires. And it runs on multiple platforms and clouds – both as a bare-metal install and a global level service. Some clients aren’t migrating what they have, they are eyeing PostgreSQL for future projects. Some have third-party solutions that require a PostgreSQL back-end.

In all these cases, we’ve seen the requirements our clients have, and in line with meeting their needs, we’ve started a “Postgres Tiger Team” within the company. These technical professionals are currently training and implementing PostgreSQL solutions on Windows, Linux, Containers and Clouds. We are taking SQL Server tickets and issues we have, and one team member will “break” their PostgreSQL installation and assign a ticket to another team member to fix, just like we would with SQL Server. They are writing blogs, teaching classes, and keeping the rest of the company up to date on PostgreSQL. And they are learning some interesting things along the way. You’ll see some blog posts here shortly about their journey. You’ll understand a little more about who they are, and you’ll get very frank and honest impressions about the good, the bad, the process, the learnings and much more as they take on this extra responsibility in their professional training.

As a company, we’ll keep our focus on Microsoft SQL Server as we add new platforms our customers ask for. SQL Server is an amazing product with fantastic capabilities, and we’re committed to have the best technical support for it. Personally, I think SQL Server has a juggernaut of a path forward into the future. As a former SQL Server Microsoft team member, some of my blood, sweat and tears are in that codebase, and I am very excited about the new features I see coming out.

We hope you enjoy this series, and learn a little something along the way. I’ll be presenting a full one-day, hands-on workshop this Fall at the Live 360 conference. I hope you can join us there.
https://live360events.com/events/orlando-2026/sessions/friday/dpf01-hol-wksp-postgresql.aspx

The post The Straight Path to PostgreSQL appeared first on SQL Server Consulting - Straight Path Solutions.

By Day 90 you should feel less blind and less on your own with SQL Server. Our clients describe it as the ability to sleep at night without worrying about their SQL Servers. You’re onboarding with a vendor, but it shouldn’t feel like it.

This post talks about what a healthy first 90 days should look like and where things commonly get harder than the sales conversation implied so you can be aware of it, look to make your part smoother and call out where it feels off. This is part of our Buying DBA Services series of posts. Whether you buy from us or a friend in the business, we want you to be equipped as you make that selection.

Prefer to watch? I sat down with Evan, our COO and the person who oversees our onboarding process, to talk through what actually happens after a new DBA as a Service client signs, what tends to slow onboarding down, what happens when there’s already a fire, where we’ve gotten onboarding wrong, and what should feel different by Day 90.

Define What Success Looks Like Before You Start

This is something pretty important and it should be part of your kick-off call. Evan got to this in the video and I wanted to add it to the post. Whether you work with us or another provider:

You should tell your DBA provider what success looks like to you.

That sounds obvious, but it’s easy to skip. Your provider may have a perfectly good 90-day onboarding checklist. They may get monitoring installed, review your backups, find configuration problems, check integrity, document the environment, and feel like they knocked the onboarding out of the park.

Meanwhile, you’re wondering why nobody fixed the performance problem that caused you to hire them in the first place.

That’s a failed onboarding, even if every box on the provider’s checklist is green.

Before you start, I’d make sure both sides can answer this question:

“Ninety days from now, what needs to be different for us to consider this relationship a success?”

The answer might be fewer outages. It might be getting your DBA out of the 2 AM alert business. It might be knowing whether your backups can actually be restored. It might be getting a specific performance problem under control. Or it might simply be understanding the risks you don’t know about today.

The provider should have an onboarding process. But your definition of success needs to be part of it.

What happens immediately after signing?

Onboarding with us doesn’t always wait for the official start date.

After signing, a provider typically sends welcome and contact information, schedules a kickoff meeting, provides onboarding documentation and forms for you to use for access. They begin identifying key contacts, and usually start access work as soon as you are ready. In many cases the client can already reach the team for advice or issues, and monitoring or health-check work can begin as soon as usable access exists even if it’s a bit ahead of the “official start date.”

At Straight Path, we like to start each DBA as a Service retainer on the first of a month and we limit ourselves to two to three active onboardings per month, so no one falls behind.

Signing on August 15 for a September 1 start does not automatically mean everyone sits idle until September 1. Many providers (including us) would rather begin solving access and visibility earlier and effectively give the first quarter a little extra runway than spend the first several weeks of the official engagement still blind.

What access does a Remote DBA team need?

A DBA team needs sufficient access to actually perform DBA work. That commonly includes remote connectivity, appropriate SQL Server permissions (SA access is really necessary to truly effectively be your DBA team. We can use a PAM tool and have non-admin and admin accounts, but it’s just necessary to succeed.) Jump-servers need to be setup for many providers, including us, and coordination around MFA/PAM/VPN needs to happen. Firewall internal and external connectivity for monitoring needs to be solid.

Effective working access is one of the biggest variables in onboarding speed.

How customers can make this easier

• Identify who owns VPN and security access before kickoff
• Test credentials before sending them
• Document VPN, MFA, and PAM procedures
• Determine who can grant SQL-level access
• Bring the MSP, network, or security team into the process early when needed
• Know who actually owns administrative access to vendor-managed systems

A real-world pattern worth noting: some organizations discover during onboarding that they do not actually possess the level of SQL Server access they thought they did, especially around vendor-managed applications. We’ve seen this happen at Credit Unions and a couple radiology practices that have “over-protective” vendors. That discovery itself can surface risk.

How us providers can make this easier

• Provide options for shared access and use a SOC/HIPAA/PCI compliant tool that a client can use as an option with logging, MFA and controls already
• Document your needs ahead of time and get that to the clients before a sales decision is made
• Provide a secure portal to share information consistently
• Suggest an access kick off meeting – sort of a pre-kick off kickoff meeting where the access is squared away.
• Ask the provider to test the access first, remind them that onboarding eats into billable hours and we want to use those hours to make a difference.

Days 1–30: Stop being blind

The primary job in the first month is visibility. Visibility for the Remote DBA provider and with their tools, hopefully much more visibility for you and your support teams.

Clients often hire a DBA provider because of a problem that is seen by all and obvious to the business… Performance, migration, upgrade, recurring outages, a recent ransomware, a failed compliance or regulatory exam, capacity, or technical debt. Those matter. But before spending the bulk of the engagement tuning a query, the provider should understand whether the environment is fundamentally recoverable and safe enough to work on. I always call that, “the things that we can’t sleep at night knowing you have wrong.”

Initial work should look for high-risk issues such as missing or broken backups, including the ever-present “rogue backup” we find with sp_CheckBackup, restore/recoverability problems, corruption, missing integrity checks, serious configuration issues, broken maintenance, capacity or storage threats, obvious HA/DR risk, and dangerous preexisting conditions (Yes I mean it’s not normal to get a stack dump and failover every day when change tracking cleans up with the busier afternoon cleanup…)

Two trains on the tracks

Sometimes we have to do what I call “putting two trains on the tracks” in sales and onboarding calls… We have a team for a reason and we can multi-task even for one client.

One train deals with the scary things capable of causing data loss, outages, or serious business risk. The other deals with the reason the client originally called.

A good provider should not refuse to touch the performance problem until a 97-point checklist is complete. It also should not spend 30 hours tuning queries while nobody notices the database has not had a valid backup in six weeks. It’s balancing those that makes a difference. The best tuned database doesn’t matter when Murphy swings by and breaks it all hard because we all agreed to save that “boring” stuff for later.

When should monitoring be installed? Ideally very early, even before the official start date is what we strive for when the access is good and we sign early enough. Installing monitoring is not the same thing as managing the environment, though. Once data starts flowing, someone still has to review it, understand what matters, tune noise, escalate real risk, learn what is normal for this environment, and prevent recurring alerts from becoming “the one we ignore.” That first month we are titrating alerts, negotiating on which errors are really “acceptable”, fixing maintenance, and trying to make the daily checks more green and make your server become a happier, quieter server in our dashboards.

What happens if something dangerous is found immediately? There is no true catch-all answer. Every company has different change-management expectations. Some say “just fix it.” Even then, a good provider will explain what was found, why it matters, and what is about to change. Anything requiring downtime needs an approved plan or window. If something is truly dangerous and the client is not responding, escalation may move from tickets to emails to phone calls to increasingly more direct communication. Part of onboarding is learning how your company makes technical decisions and approves change.

How are priorities decided? A useful model is the one I talked about in the health check blog post last month: Finding → Risk → Priority → Owner → Action. In practice the provider and client has their own priorities, but a provider also is coming at this from being burned a LOT. Corruption, for example, is rare for most folks – but a SQL Server consultancy sees it all the time and gets those phone calls where the answer is “sorry we can’t do anything, you should have called us last week.” The provider may be most concerned about recoverability; the client may be most concerned about the performance issue users feel every afternoon. Both matter. Sometimes work can proceed in parallel. Sometimes available hours or severity mean lower-priority work genuinely has to wait.

How many DBA hours does onboarding consume? It varies substantially. For many engagements it falls in the 5–10 hour range, but access problems, security processes, multiple teams approving the various accounts and VPNs and firewalls, poorly documented VPN/PAM systems, vendors with SA access approving access, and unavailable customer resources can stretch it.

Sometimes the right answer for us is to delay the formal onboarding date rather than burn a client’s paid DBA hours fighting an access problem they are not yet ready to solve.

What should be different by Day 30? Green everywhere is not the test. But the big risks absolutely should be calming down.

By approximately Day 30, monitoring and daily reporting should be flowing, major access issues should largely be resolved, the primary relationship should be established, the scariest findings should be decreasing, backup and recoverability gaps should be understood and being addressed or, frankly, solved where the provider can just fix it, missing maintenance should be improving, and overall stability should be moving in the right direction. A terrible environment may still have plenty of red. It should simply be safer than Day 1.

How disruptive is onboarding to your team? There is some disruption. Someone (or 3 teams) on your side will need to help with access, answer environment questions, and participate in prioritization. We’ll send inventory documents that your team needs to fill out identifying owners and purposes of servers. The better providers keep that load as reasonable as possible, but it is not zero. It does go down with time once we are onboarded. We do a check-in call at least monthly and the more folks impacted by the SQL Servers and who impact it that show up, the better. Though we find it a lot easier with one owner on the client side ultimately responsible for the final answer and direction.

What if a major incident happens in week 3? A provider that has already established access and started the process of learning the environment should be able to respond without starting from zero. The response will still be constrained by the access, change control, and vendor relationships that exist at that moment, but that’s why you hired us – and the DBA life is a fun life with new challenges and problems – a good team is jumping in and helping, but success may not come as quickly as it would have on day 67.

Days 30–60: Stabilize and begin solving the original problem

The second month should start moving forward in a more steady way.

You are still remediating findings, reducing scary risks, cleaning up remaining access issues, tuning alerts, and challenging recurring “acceptable” errors. The support team has stabilized much of the environment, best practices are becoming the norm, the most critical servers are good, the other ones are getting the checks. The Lead DBA is meeting at least monthly and the performance, migrations, upgrades, architecture, technical debt, or projects you brought the DBA as a Service team in for are being addressed and planned.

This is the transition from pure onboarding and discovery toward normal managed DBA work and a DBA relationship.

When does the Lead DBA actually know your environment? There is no magic date. Context begins accumulating immediately through sales notes, kickoff, onboarding data, and early tickets. “Knowing the environment” does not mean memorizing every database name. It means understanding the applications, business priorities, unusual vendor requirements, maintenance windows, decision-makers, recurring issues, known landmines, architecture, what absolutely cannot go down, and what the client is trying to accomplish.

You should not have to reintroduce your company every time you open a ticket and the consistency from the lead DBA being involved and meeting regularly really helps that. And the full team is made aware of what is going on with the clients because we let our team take vacations.

What happens if the plan is clearly undersized once the real backlog is visible? This can happen. At Straight Path we often talk about that risk in sales calls where we have our discussions about managed DBA services pricing. A good provider raises that potential directly instead of waiting for the “Oh crap” moment. Options usually include adjusting the plan, extending the timeline, or accepting that some items will remain lower priority. It should depend on the needs and budget of the client – and that’s why we used to call our service “FlexDBA” – clients can still flex up or down when the needs dictate.

Days 60–90: Heading towards a normal rhythm

By the third month you are learning what the real ongoing relationship looks like. You should have met with your main contact at least a few times towards the end of that 90 days.

Initial firefighting should be declining. There is actual evidence of how many hours the environment consumes, what recurring responsibilities exist, what projects are coming, how much technical debt remains, and whether the current service level is properly sized.

This is the natural point to ask what success looks like three, six, and twelve months out, and whether the service level still makes sense for the next quarter. And at Straight Path that’s what we do – we want to plan for the future with you. “Where do you want to be in a year?” is something we should know by the end of the first quarter and a plan should be formed that helps get there. Titrated to the budget and your competing priorities and the time we need.

What can make the first 90 days go badly

Common failure patterns:

• Access is not ready. Credentials untested, no clear owner, security teams not aligned
• Nobody can approve anything. Risk is found but remediation cannot be authorized
• Prolonged email tennis between provider, MSP, sysadmin, and security. When that happens, stop emailing and get the right people into a meeting
• Fun with Software Vendors. An application vendor complicates ownership and no one is sure where vendor responsibility ends
• Expectations were never set and aligned.
• The client expects the provider to “take everything over tomorrow”. That is fine but we need the access yesterday for that to happen
• The plan is undersized relative to the real backlog. This is a real risk, it’s why often in sales calls when we price per hour – I’ll suggest a lot of clients move to Gold or Diamond the first quarter and give them a one time rollover of all unused hours one quarter – 45 hours with Gold saves the client about $1,500 over 45 hours with Silver and overage.

What you should expect by Day 90

From a healthy DBA as a Service relationship by Day 90:

• The provider understands the environment at a useful level
• Access is established
• Monitoring is producing useful information
• Serious risks are known and being addressed
• Urgent problems are less frequent
• Priorities are understood
• Communication has a workable rhythm
• There is a forward plan
• You know who to call; they know who you are
• The relationship no longer feels new

They should begin to feel like part of your team rather than a vendor or ticket queue. If you’ve ever watched a pet cat or dog go to sleep, you know that deep sigh they do right before they fall asleep? Content, happy, calm? You should be able to do that (for a brief moment, before you wake up and remember we’re only there for your database world. Sorry…)

How transparent should the provider be about remaining risk at Day 90? Very. A useful conversation includes what is improved, what is still outstanding, what is deferred and why, and where residual risk remains. “Everything is fine” is rarely accurate. Honesty and transparency go a long way to a long-term relationship. You should know the risks that still exist and the plan around them.

What this looks like at Straight Path

The expectations above are what any healthy DBA as a Service relationship should produce. How individual providers deliver them varies.

At Straight Path the model includes a named Lead DBA, support from the broader team, structured daily review processes, and deliberate attention to relationship continuity and internal accountability so context does not live in only one person’s head.

This is not the only valid way to deliver the service. It is how we have chosen to do it.

Closing

The first 90 days should not be measured by whether every health-check item has turned green.

Measure whether you are less blind. Measure whether the most dangerous things are becoming less dangerous. Measure whether recurring problems are starting to disappear. Measure whether the DBA team understands what actually matters to your business. And measure whether you are beginning to spend less time worrying about SQL Server and can sleep even just a bit better.

By Day 90 you should not feel like you are still onboarding a vendor. You should feel like you have added a DBA team to your existing team. You should feel confident in the health of your database estate. Otherwise you just onboarded one more thing to worry about.

The post What Should Happen in the First 90 Days of a Remote DBA Relationship appeared first on SQL Server Consulting - Straight Path Solutions.

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.

A quick chat about ways this can go wrong if you’d rather watch:

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.

Video thoughts on the calculations and the approach if you want to hear some candid thoughts:

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.