How much does free SQL monitoring really cost?

I built SQLWATCH Open Source. Thousands of DBAs have downloaded it, deployed it, built their monitoring on top of it — and emailed me when something did not work the way they expected. I am proud of that. Building something people actually use is not something I take lightly.

But after eight years, I need to tell you something that most Open Source builders never say publicly. DIY SQL monitoring costs more than SaaS. There, I said it (this statement will probably start a fight).

Before you all get too excited — this is not a sales pitch and SQLWATCH Open Source is not going anywhere. And it is absolutely not a dig at the free tools our community builds — Erik Darling’s scripts, the First Responder Kit, sp_WhoIsActive and many others are excellent, built by people I like and respect, and they all have their use. This post is about my own project, and what eight years of running it taught me. Bear with me.

Why I built SQLWATCH Open Source in the first place

I have been a DBA for 25 years. I have worked with SQL Server in every configuration you can imagine — small businesses on a single VM, enterprise estates with hundreds of instances, MSPs managing a dozen client environments from one console.

Across all of it, there was one consistent gap: monitoring tooling that was either vastly overbuilt for what most teams needed, or priced as if every DBA worked for a FTSE 100 company.

SQLWATCH Open Source was my answer. A focused, SQL-native monitoring solution that a competent DBA could deploy, understand and own. Free. No vendor lock-in. No subscription creep. No feature bloat.

I got a lot right. The architecture was solid, the data model was sensible, and the community was genuinely good — full of smart DBAs who contributed meaningfully and asked sharp questions. But I also saw something I did not fully anticipate. Something that plays out slowly, over months and years, until one day it becomes a crisis.

Free monitoring is a bit like a free puppy

The licence is free, yes. But Open Source monitoring is a bit like a free puppy. The puppy itself costs nothing. The food, the vet, the chewed furniture and the dog-sitter when you go on holiday — those cost plenty. And here is the important bit: usually only one person in the house knows what the puppy eats, when it needs walking and which vet it is registered with.

Keep the puppy in mind. We will come back to it.

The one-person problem

Let me be direct about something the Open Source community does not like to acknowledge.

SQLWATCH Open Source has one maintainer. Me.

That means feature velocity was constrained by my available evenings — real evenings, alongside consulting work and everything else. Bugs got fixed when I found time. The roadmap was whatever I decided it was, based on GitHub issues, messages, and my own view of what mattered.

For most users, that is absolutely fine. They deploy it, it does what they need, they do not push it hard. And if that is you — genuinely, carry on.

But for teams where SQL monitoring is a critical operational dependency, single-maintainer Open Source creates a category of risk that never gets priced in at deployment time. What happens when I stop? What is the support path when the version you are running has a regression? What is the escalation route when you need a feature for a compliance requirement and the queue is long?

These are not hypothetical questions. They are questions I have received, in various forms, from teams who deployed SQLWATCH Open Source in good faith and are now reckoning with the gap between “an Open Source project” and “production-grade software with support”.

Where the puppy money actually goes

Let’s break down the actual cost of running self-hosted Open Source monitoring in production:

DBA hours. Deployment, configuration, tuning, patching, troubleshooting. The initial deployment might take a day. The ongoing maintenance — keeping it running, updating it, debugging edge cases — is a recurring cost that most teams do not log anywhere. It just disappears into DBA capacity. Nobody invoices it, so nobody sees it.

Hosting. Someone owns the VM. Someone pays for the storage. Someone manages the dependencies. None of that is zero, even when it is absorbed into a broader cloud bill.

The knowledge silo. This is the one that kills teams, and it is the puppy problem in its purest form. One DBA set it up. They know why the alert thresholds are set the way they are, which queries are excluded and why, where the retention policies live, what the custom dashboards are doing. Then they leave. Or they go on holiday. Or they are busy with another incident. And the rest of the team inherits a monitoring stack they only partially understand, on infrastructure they cannot fully account for. Nobody else knows what the puppy eats.

The failure cost. When Open Source breaks in production — and it does, because all software breaks — the recovery path is GitHub issues and community forums. There is no SLA. There is no engineer to escalate to. The cost of that failure lands entirely on your team, usually at the worst possible time.

Opportunity cost. Every hour a DBA spends maintaining the monitoring tool is an hour not spent tuning queries, reviewing schemas or doing capacity planning — the work they were actually hired to do.

I have had teams do this calculation after a major incident or a key person leaving. The number is always higher than they expected. Sometimes much higher.

The licence costs nothing. The key-person dependency costs everything.

But it works, why change anything?

Sure, I hear you: “It has been running for three years without a problem. Why would I touch it?”

Fair enough. The risk is not in the day-to-day. The day-to-day is lovely. The risk lives in the exceptions — a key person resigns, a security review lands, a scale event hits, a procurement audit starts asking questions. Monitoring that “just works” and monitoring that is operationally owned look identical right up until one of those days. Then they look very different.

Do I think every team running SQLWATCH Open Source is sitting on a time bomb? No, absolutely not. Plenty of environments will never hit these problems. But you should know, honestly, which kind of environment yours is — and 9 out of 10 teams I speak to have never asked themselves the question.

The procurement wall

Here is a scenario I have watched play out many times. A DBA deploys SQLWATCH Open Source. It works well. Everyone is happy. Then the organisation goes through a security review, a compliance audit, or a vendor rationalisation exercise, and the questions start:

• Finance: “Who is the vendor?”
• Security: “What is the support model and the disclosure process?”
• Legal: “What is the licence, who maintains it, and what happens if it is abandoned?”

The answer to all three is some version of “it is Open Source, maintained by one person, and there is no commercial agreement”.

That answer does not clear procurement. Not in 2026, and not in any organisation with a functional security posture. The project stalls. The tool keeps running, but on borrowed time — deployed, used, but not owned, not supported, not signed off. A grey zone.

I have seen this happen with SQLWATCH Open Source specifically. Teams who wanted to make it their standard monitoring platform could not, because there was no vendor to sign the contract with. That was a strange thing to watch as the creator: the software was good enough, and it still lost.

Who monitors the monitoring?

This one is almost darkly comic, until it happens to you.

The VM running your monitoring develops a performance issue. You go and check the monitoring. The monitoring is the performance issue — a runaway collection job, a query that has grown expensive as the data set scaled, a retention policy that was never trimmed.

Your monitor needs its own monitor. Quite the paradox.

This affects every self-hosted monitoring tool, not just SQLWATCH — I blogged about how monitoring affects the monitored server some time ago, and the observer effect is very real. But the operational question remains: who gets alerted when the alerting stack is the problem? In a self-hosted world, the answer is usually “nobody, until a human notices”.

What production teams actually need

After eight years of watching how teams use SQLWATCH Open Source, I have a fairly clear picture of what they actually need from production SQL monitoring:

• An SLA. Not a community forum. A human on the end of a support ticket who can escalate a production incident.
• Multi-tenancy designed in, not bolted on. MSPs and consultancies have been working around single-tenant architectures for years. It does not scale.
• A vendor procurement can sign. A commercial relationship, a licence legal can audit, a support model security can assess. That is not bureaucracy — that is what responsible software procurement looks like.
• A predictable release cadence. Open Source moves at the speed of one person’s spare evenings. Organisations planning upgrades and maintenance windows cannot schedule against my calendar.

Why I built SQLWATCH Cloud

I built SQLWATCH Cloud because I reached the same conclusion most mature DBA teams eventually reach about self-hosted Open Source monitoring.

The Open Source version got the fundamentals right — the monitoring logic, the data model, the approach to SQL performance telemetry. I am proud of that work and it is not going away. But the operational model — single person, self-hosted, no defined release cadence, no procurement path — is not the right model for production monitoring at scale.

Cloud is not a different product built by different people who do not understand SQL Server. It is the next version, built by the same person who built the original, with eight years of production observations baked in. Multi-tenant from the ground up. Hosted and managed, so there is no self-hosting tax and the “who monitors the monitoring” problem becomes my problem, not yours. Supported, with actual support. And it clears procurement: finance has a vendor, security has a contact, legal has a licence.

There is one more reason, and I will be honest — it is a selfish one. I have a very clear idea of how SQL Server monitoring should be done: affordable and comprehensive at the same time. Free cannot deliver that — I know, because I spent eight years trying. Comprehensive takes a team of experts, and a team of experts takes revenue. The commercial model lets me hire people who are better than me at the things I am merely average at, and build something one person’s spare evenings never could.

Sure, I hear you: “you could have taken investment and kept it free.” Perhaps. If you want to invest and keep SQLWATCH free, give me a shout.

Is Cloud for everyone? No. If the Open Source version covers your needs and you are nowhere near the ceiling I have described, keep running it with my blessing. I would rather you monitored your SQL Servers with my free tool than not at all.

If you are running SQLWATCH Open Source today

SQLWATCH Open Source is staying available. I am not pulling it. The community built real things with it and I respect that enormously.

But if you are running it in production and starting to feel the weight — the unlogged DBA hours, the procurement questions, the one-person-knows-everything risk — I would rather have that conversation with you now than watch you reach a crisis point at 3am.

There is an offer for Open Source users who want to move to Cloud. Message me and I will tell you about it — it is not in a blog post, it is in that conversation. Or start a free trial and tell me you came from the Open Source version. We will make the transition worth your time.

Conclusion, the honest bit

If you take one thing from this post: write down why your alert thresholds are set the way they are, today, whilst the person who set them still works with you. Do it whether you stay on Open Source or not. Thinking about key-person risk is cheaper than living through it.

The question is not whether self-hosted Open Source monitoring has a ceiling. It does — I built it, so I get to say that. The question is whether you are still comfortably below that ceiling, or whether you passed it a while ago and nobody has noticed yet. These problems do not announce themselves.

So — who owns your monitoring VM? Do you know? Does anyone? Let me know, I genuinely want to hear the answers.

Have a good, key-person-dependency-free weekend!