Chapter 9: The AI-for-DBAs Community¶

Here is the chapter I cut.

It was a manifesto. It had sections with names like "The Coming Displacement" and "Reclaiming the DBA Role." It made arguments about professional survival. It spent a lot of time explaining why database administrators should care about AI rather than just showing them something worth caring about.

Manifestos age poorly. DBAs need something they can use on Monday morning.

What the Community Is¶

"AI for DBAs" is a working community of practice built around one concrete idea: the interpretation gap between raw diagnostic data and actionable decisions is closeable, and the people who should close it are the ones who understand both ends of that gap.

That means DBAs who understand SQL Server deeply enough to know which signals matter. Not AI researchers. Not platform engineers who have never read a deadlock graph. People who have been paged at 3 AM and solved the problem before business hours.

The community exists as a place to share what that combination produces: diagnostic patterns that work, system prompt templates refined against production workloads, tool designs that do not break under the conditions real SQL Server environments create. Not theoretical architectures, but working code, against live systems, with honest notes on what failed and why.

The "AI for DBAs" identity listed under my volunteering work is not an honorary title. It is the active project. Bob is the technical artifact. The community is the mechanism by which Bob becomes more than one person's home lab experiment.

The Real Problem with DBA Knowledge¶

The skill distribution problem in the DBA profession is something Chapter 3 outlined: too many senior DBAs spread across too many instances, junior people who lack the pattern recognition that only comes from years of exposure, the middle layer that is genuinely rare and genuinely expensive. That distribution has not changed meaningfully in the decade I have been paying attention to it.

What has changed is the tooling available to close the gap.

When I started at Chickasaw Nation in 2007, the knowledge transfer mechanism was sitting next to the senior DBA and watching. That is still the best way to learn, and it is not scalable. By the time I was doing HIPAA compliance work at Lumeris in 2017, the situation was: one DBA (me), many databases, PHI on the line, and no one to consult for the edge cases except documentation and SQL Server forums. Not ideal.

At Entergy, through ComTec from 2020 to 2024, the monitoring toolchain was sophisticated but the interpretation still landed on humans. NERC CIP auditing requires 100% compliance, and achieving that required custom SSRS reports that a human read every week. The reports were good. The human-reading-them step was the bottleneck. I automated about 70% of the routine analysis away with PowerShell by the time I left, but the remaining 30%, the non-routine findings that required judgment, still required a DBA.

That 30% is what Bob addresses. And it is where the community work matters most, because the knowledge required to handle that 30% is distributed across thousands of people who have been doing this work for years. It is not in any single repository. It is in the collective memory of a profession.

DBAs share knowledge generously on forums. Ask a question about a wait stat on DBA Stack Exchange and you will get a good answer within hours. Ask for someone's complete monitoring agent with deployment instructions and you will get silence.

The gap between "willing to share a query" and "willing to share a system" is real and has multiple causes.

First: context collapse. A diagnostic query is self-contained. A monitoring system embeds assumptions about the environment: schema names, connection strings, operational windows, escalation contacts. To share it as something another DBA can actually use, you have to strip the context out and replace it with configuration points. That is real work.

Second: embarrassment. The code I wrote in the early Bob prototypes was functional and ugly. The kind of code you do not want anyone to read. Getting it to the point where you are comfortable having someone else run it requires a refactor pass that takes time.

Third: liability anxiety. If you share a system that applies fixes automatically and someone runs it against a production database they do not fully understand and something breaks, whose fault is that? The cultural answer in the DBA community has historically been: not worth the risk.

The community I am building handles these by changing what "sharing" means. The primary artifacts are not finished systems. They are patterns: diagnostic patterns that work in certain conditions, prompt templates refined for specific failure classes, tool designs that have been validated in production. Those are shareable without the full context problem. They require the person who uses them to do the integration work, which means they understand what they are running before they run it.

The Prompt Library¶

The most immediately valuable thing the community produces is a library of system prompt templates, each annotated with the failure class it was designed for, the model it was tested against, and the production conditions under which it worked.

Not vague templates. Precise ones. Here is the shape of a prompt template entry:

TEMPLATE: deadlock-cycle-diagnosis
FAILURE CLASS: Recurring deadlock on same two tables
TESTED AGAINST: qwen2.5:14b, qwen2.5:32b
PRODUCTION CONDITIONS: OLTP workload, 50-200 concurrent sessions, SQL Server 2019

SYSTEM PROMPT:
You are analyzing a SQL Server deadlock graph. The deadlock involves two or more
sessions blocking each other in a circular dependency. Your task is to identify:
1. Which two objects (tables, indexes) are at the center of the cycle
2. Whether the cycle pattern suggests a missing index, an ordering problem in
   application code, or a transaction isolation level mismatch
3. A specific T-SQL test query that would confirm your hypothesis

Output as JSON: {"root_cause_hypothesis": "...", "confidence": "LOW|MEDIUM|HIGH",
"confirmation_query": "...", "recommended_fix": "..."}

Do not fabricate table or index names. Use only what appears in the deadlock graph.

NOTES: This template performs poorly against deadlocks involving more than four
sessions. For high-cardinality deadlock graphs, use the deadlock-correlation template
which feeds the graph through a preprocessing step first.
# source: bob@c549c88

That level of specificity is what distinguishes a useful template from a general suggestion. The "NOTES" field is as important as the prompt itself. Knowing the conditions under which something fails is knowing the conditions under which you can trust it.

The Community Practice¶

Shared templates are necessary but not sufficient. What makes a community of practice work is iteration: someone uses a template, finds a condition where it breaks, posts the failure, the template gets revised, and the revision gets used by the next person.

That cycle requires a feedback loop with low friction. The community infrastructure for this is straightforward: a Gitea repository at http://10.0.0.80:3000/hyp3rsoft/ai-for-dbas-community (a separate repo from Bob itself), with prompt templates as structured YAML, contribution guidelines that focus on reproduction steps for failures rather than just success stories, and a tagging system that lets people filter by SQL Server version, model size, and failure class.

The harder part is cultural. Senior DBAs are the person with the answers. That identity makes posting failures hard. Saying "this prompt I thought was good produced a hallucinated recommendation in this specific case" requires a different professional orientation. It requires the framing that sharing failure information is a contribution to collective knowledge, not a confession of incompetence.

That framing is one I am actively trying to model. The chapter on the rollback-first pattern in this book exists because Bob applied a bad fix once before the snapshot requirement was enforced, and fixing the aftermath cost half a day. That story is in the book because the lesson is worth more than the embarrassment costs.

Why This Matters Beyond One Agent¶

The honest answer to "why should a DBA care about AI" is not about job preservation. It is about leverage.

The DBAs who will benefit most from this community are the ones who are already stretched too thin: one person managing twelve instances, on-call every other week, no one junior enough to delegate the routine work to. Bob, configured well with patterns from the community library, is not a replacement for that person. It is the person's ability to be in two places at once: monitoring the routine while the DBA focuses on the things that actually require judgment.

The pattern library is how one person's hard-won knowledge about what a SOS_SCHEDULER_YIELD spike looks like at 2 AM becomes something fifteen people can act on without earning it themselves. That is not democratization in the abstract sense. That is a specific, practical transfer of diagnostic expertise from the people who have it to the systems that can apply it at scale.