Chapter 3: AI for Everyone¶
There is a version of the Bob story that stops at "I built a tool for my own use." That version is fine. The tool works. It saves time. End of story.
But that is not the story I want to tell, because I do not think the problem Bob solves is mine alone.
The DBA profession has a specific skill distribution problem. The senior people, the ones who have been reading query plans since before the internet was fast enough to stream video, are expensive, overextended, and in most organizations, on a slow path to retirement. The junior people have energy and can write T-SQL, but they lack the years of exposure that turns a wait stats snapshot into a diagnosis. The middle layer, someone with five to ten years who can read a query plan and knows what SOS_SCHEDULER_YIELD waits mean at high volume, is genuinely rare.
This means most organizations are under-resourced on SQL Server monitoring. The senior DBA is spread across too many instances. The alerts fire too often or not enough, because tuning alert thresholds requires the same expertise that's in short supply. And when the junior person gets paged at 3 AM about a high-CPU event, they open the monitoring dashboard, see a lot of red, and call the senior DBA anyway.
That pattern is not sustainable. It is also not a money problem. You can throw budget at it by buying managed monitoring services, and plenty of organizations do. But managed services have their own problems: data leaves your environment, the service has to be generic enough to work for thousands of customers, and the recommendations it generates are templated. They do not know your application. They do not know your data access patterns. They know what slow queries look like in general.
Bob knows your specific instance. It runs in your environment. It has been watching your specific workload. That is a different kind of intelligence.
The "AI for Everyone" claim is specific: the interpretation gap I described in Chapter 1 is solvable for organizations that cannot afford to staff it with senior DBAs.
Regulated-industry DBAs have the most to gain here and have been the most systematically left out of the AI monitoring conversation. A DBA at a hospital network, an electric utility, a regional bank: these are the people with the hardest monitoring problems, the highest stakes for getting it wrong, and the fewest options for bringing in cloud AI to help. HIPAA covers protected health information. NERC CIP covers critical infrastructure data. PCI DSS covers cardholder data. None of those standards were written with "send your diagnostic data to a third-party inference API" as an approved control. They were written before that was a real question.
Local inference does not solve the regulatory compliance problem automatically. You still need to document your data processing, maintain access controls, and audit what the agent is doing. But it eliminates the third-party data processor problem entirely, which removes the most difficult compliance question from the table. A CISO who needs to sign off on a DBA using an AI monitoring tool can say yes to "runs on our hardware, data never leaves our LAN" without a six-month vendor review. That changes which organizations can use the tool.
The math is this. A local LLM running on a reasonably modern GPU costs roughly $30 to $80 per month in electricity. A cloud API for the same inference volume costs hundreds to low thousands of dollars per month, and more importantly, it means your query plans, your wait stats, your application-specific diagnostic data, leaves your network. For a financial services client, a healthcare organization, any entity under data governance pressure, that is not a tradeoff you can make casually.
A dedicated machine running Ollama with a model capable of SQL Server reasoning costs somewhere between $500 and $3,000 depending on your ambition, consumes a few hundred watts, and pays for itself in the first avoided incident. That calculation changes the accessibility of serious monitoring AI dramatically.
This is the sovereignty argument, and Part 2 of this book makes it at length. But the origin of the argument is practical, not political. I did not start from "I don't want to pay OpenAI" as a philosophical position. I started from "my clients have regulated data and cannot use external APIs for this," and worked backward to the local inference setup; the philosophical position came after the technical requirement.
The moment I decided this was worth building for more than myself was not dramatic. It was a phone call.
A DBA I had worked with a few years earlier was getting paged every third night because his company's monitoring tool was generating false positives he could not tune down without also missing the real ones. He knew what to look for. He had been doing this for fifteen years. The problem was not expertise. The problem was that his expertise was not available at 2 AM when he was asleep and the alert fired. He would wake up, look at the same wait stats he had looked at a hundred times, determine it was the same network IO pattern that always resolved itself in ten minutes, go back to sleep. Then thirty minutes later it would fire again because the monitoring tool had no memory of the first alert.
That conversation was the one that clarified the mission. The interpretation gap was not just my problem. It was a profession-wide problem. And the solution was not more training, because the people getting paged at 2 AM already knew their databases. The solution was a system that could hold the expertise of the senior DBA and apply it continuously, without needing to wake anyone up.
The line on the resume, "AI for DBAs: Creator and strategist for communities focused on the future of data management," is where that mission sits publicly. The vision behind it is narrower and more specific than the phrase suggests: get enough senior DBAs to encode their diagnostic reasoning into systems like Bob that the knowledge stops being locked inside individual people's heads.
The hardest people to reach with that argument are the DBAs who are most qualified to act on it. Senior DBAs tend to be skeptical about automation for good reasons. They have seen automation fail in expensive ways. They have cleaned up after systems that were confident and wrong. They carry a healthy distrust of anything that promises to replace judgment with code. That distrust is correct in general, and the argument Bob makes is not that code replaces judgment. The argument is that your judgment, encoded as structured instruction and system prompt context, can work while you sleep. The code is just the delivery mechanism for expertise you already have.
"AI for Everyone" also has a community dimension.
DBAs who build their own tooling tend to share it poorly. The culture of the DBA community historically has been generous with knowledge, SQL Server forums have always been active and helpful, but stingy with code. Sharing a diagnostic query is common. Sharing a full monitoring agent with deployment instructions is rare.
Part of that is legitimate IP concern. If you build something that gives your organization a competitive advantage, you do not necessarily want to open-source it. Part of it is simpler: sharing code requires documentation, and documentation takes time, and DBAs are usually busy.
Bob is meant to be a template, not just a product. The architecture documented in Part 2 is intentionally separable from my specific infrastructure. The three-layer design works for a single SQL Server instance at a small organization or a fleet of instances at an enterprise. The Ollama integration is not tied to the specific model I run. The MCP tool set is extensible by design.
The vision is a community of DBAs who have adapted the architecture to their own environments, contributed new tools, stress-tested the system against failure modes I have not encountered, and generally made it better than I could alone. The hard part of that vision is not technical. It is social. Getting DBAs to share working code, to trust that what someone else built is actually useful and not a trap, takes trust that has to be built over time.
That is an ongoing project. Chapter 9 talks about the community side in more detail.
There is a last thing worth naming in the origin section, before Part 2 gets into the machines and the protocols.
Building Bob changed how I think about the role of experience in technical work.
I spent a lot of years thinking that the value I added as a DBA was primarily in the form of knowledge. I know what this wait stat means. I know what this query plan shape indicates. I know which configuration knobs to reach for when memory pressure looks like this. That knowledge was hard-won and genuinely useful.
What I learned building Bob is that the value is also in the questions. What to ask. Which signals to correlate. When to look at the infrastructure layer instead of the query layer. When to escalate instead of fix. When to leave it alone because the apparent problem is the system responding correctly to unusual load.
Those questions are not encoded in DMV documentation. They come from experience. And they can, to a meaningful degree, be encoded in a system prompt. You can write down what you know, what you look for, what your diagnostic decision tree is. When you do that, the AI has your framework to reason within. You are not asking it to invent DBA expertise. You are giving it yours, and asking it to apply it faster than you can.
The tool works because a senior DBA built it. It will be useful to someone who isn't a senior DBA because the senior DBA's reasoning is baked into it. That is the democratization story: not "anyone can use AI to do DBA work," but "a DBA can capture their expertise in a form that works when they're asleep."
The hardware for that system lives on a server in my home lab, and it is more capable than the price suggests. Chapter 4 walks you through it in detail.