SQL and AI - I Am Staying Relevant. Are You?

I am staying relevant. Are you?

I know that is a heavy way to start. But I needed to say it first, because I have been carrying that question for over a year, and I think some of you are carrying it too. You just have not said it out loud yet. Maybe to a spouse late at night. Maybe to yourself in the car after a long call. Maybe you have not even said it to yourself, because saying it makes it real.

So let me be the one who says it first. And let me say the part underneath it too, the part I almost did not write.

I was scared. Not a little scared. Not the fashionable kind of scared you admit on a panel. The real kind. The kind that wakes you up at 4 AM and makes you stare at the ceiling and wonder if the twenty years of intuition you built, the muscle memory of reading an execution plan at a glance, the quiet confidence of knowing which wait type meant trouble, was about to be approximated by a machine that learned it in twenty seconds.

That is the fear nobody in our field wants to name. Not “will my job change.” The sharper one. What if the thing I spent my life developing can be copied by something that never lost a weekend doing it?

I want to tell you what I did with that fear. Because I did not conquer it. I still feel it. But I stopped running from it, and something changed.

One Monday morning I will never forget

Let me tell you about a specific Monday, because I think the abstraction is a way we avoid the truth.

It was month end at a mid sized finance client. 9:07 AM. The blocking started the way it always did there, like weather you could set a watch by. A senior developer, I will call him D, was on the call. His query had been named, publicly, in the previous postmortem. You could hear it in his voice, that thin careful tone people use when they are being careful not to sound defensive.

The DBA, I will call her M, had not slept properly in four nights. Her daughter had a school event she had missed on Friday. She was trying, and she was out of patience, and both things were true at the same time.

The manager was on mute, which somehow made it worse. A muted manager is louder than a shouting one.

I watched D shrink in his little video square while M explained, for the third month in a row, that the plan was flipping because of parameter sniffing interacting with a statistics refresh that ran at 8:55. I watched M’s jaw tighten every time she had to say it again. I watched a good team quietly hating each other over a problem that was nobody’s fault.

That is the room I want you to picture. Not a server. A room. Three tired humans, one muted manager, and a query that had become a character in a story nobody wanted to be in anymore.

That was the morning I stopped believing the problem was technical.

Every production incident is a room before it is a ticket.

The questions clients used to ask

For years, my inbox looked the same, and I loved it.

Why is this query slow. Why did this job fail last night. Why are waits so high. Can you review these indexes. Why is there blocking at 9 AM. Can you tune this before go live.

Reading those emails now, I feel tenderness toward them. They were simple. They were honest. There was a quiet dignity in that work. Nobody wrote articles about it. Nobody put it on a keynote slide. But it kept businesses running. It kept paychecks landing. It kept families from being woken up at 3 AM by angry phone calls.

The questions clients ask now

Somewhere in the last couple of years, the questions changed shape.

Can we make our team smarter without adding more people. Can we stop repeating the same confusion every month. Can we avoid depending on one expert every single time something breaks. Our VP read something about AI powered databases, can you help us figure out what is real. Are we falling behind by not using AI?

That last one. That is the question they are embarrassed to ask. That is the question their VP asked them and they did not know how to answer. And when I heard it out loud for the first time, I realized something that made me sit down.

It was the same question I was asking myself.

They were not asking me for AI. They were asking me for permission to be confused without being humiliated. They were asking me to be the adult in the room while the world yelled buzzwords at them.

And I could do that. Because I was confused too. And I had stopped being ashamed of it.

The language I refuse to use

Let me be blunt, friend to friend. Most of the loud words mean nothing when a backup fails.

“Unlock productivity” does not explain a PAGEIOLATCH spike at month end. It definitely does not explain it to a CFO who just wants to know why payroll is late. “Leverage AI” does not calm a developer who feels blamed for a slow query that is actually caused by a bad statistics refresh.

Buzzwords survive conference rooms. They do not survive 9 AM on a Monday.

I am not against AI. I want that on the record. I am against pretending. I am against the loud, glossy, confident language that makes good people feel small for not understanding it. I have watched that language make excellent DBAs feel stupid. Excellent DBAs are not stupid. They are the quiet backbone of entire industries, and nobody gets to make them feel like the future left without them.

What I wanted was something smaller. Something quieter. Something more honest. I wanted AI to help my clients stop repeating the same confusion over and over. That was the whole mission. No slogans. Just that.

So I built six small, practical things with my clients

None of these are flashy. None will win a keynote. None will trend. But each one changed the temperature in the room when things went wrong, and that is the only measure I trust anymore.

1. A custom SQL Server error parser

You know the moment. A SQL Server error shows up. Somebody pastes it into a group chat. Somebody asks, “Didn’t we see this last year?” Somebody says, “Ask Raj, he will remember.” Twenty minutes pass before anyone has turned the raw error into meaning. Twenty minutes of quiet panic. Twenty minutes of a manager refreshing their inbox. Twenty minutes of a junior developer praying nobody asks them a question.

Panic is the real enemy, not the error. Panic is what happens when nobody in the room has a first sentence.

So we built an AI assisted SQL Server error parser. It takes the raw error and produces a calm first response. What the error likely means. The probable root cause. The SQL Server area involved. The severity. The next safe checks. The possible business impact. And a short note on what not to do in panic.

It does not replace the DBA. Please hear me on this. It does not replace anyone. It removes the blank page fear. The DBA still owns the call. The human still decides. But now they are not starting from zero while everyone watches. They are starting from a calm paragraph. And you would be amazed what a calm paragraph can do for a scared team.

First response time on common issues dropped from around twenty minutes to about three. But the real number I care about is this. Nobody had to page M on a Sunday for the rest of that quarter.

2. An AI assisted query tuning workflow

Query tuning becomes emotional faster than most outsiders realize.

I think again of that Monday morning. D, shrinking. M, tightening. A muted manager. The workflow we built takes the query text, the plan details, wait symptoms, index information, row estimate issues, memory grants, spills, Query Store history, and runtime metrics, and produces a set of tuning hypotheses with validation steps.

The validation part mattered to me more than the suggestion part. It forces the team to ask: did logical reads actually drop. Did CPU come down. Did duration improve. Did waits shift. Did the spill disappear. Did the plan hold, or did it flip back on the next parameter set.

The real change was not technical. It was human. The conversation moved from “who wrote this bad query” to “what does the evidence say.” Nobody was the villain anymore. The evidence was the villain, or the hero, depending on the day.

Blame is what a team reaches for when it does not have evidence. Evidence is what a team reaches for when it has finally grown up.

Two months after we rolled this out at that client, D and M were getting coffee before the stand up. I am not making that up. I watched it happen on a Tuesday and I had to look away for a second so I did not say something sentimental into a work call.

That is the work. That is really the work.

3. An index recommendation reviewer

SQL Server happily tells you about missing indexes. Teams happily create them. And over time, quietly, the database becomes a graveyard. Duplicates. Overlaps. Unused indexes. Wide indexes. Slower writes. Longer maintenance windows. Creeping storage costs nobody wants to explain on the next budget call.

The reviewer takes the missing index recommendation alongside the existing indexes on that table, looks at column overlap, key order, includes, usage since last reboot, and write overhead, and produces one of four verdicts: create as suggested, modify an existing index instead, create a narrower version, or do nothing and here is why. Each verdict comes with the script, the rollback, and a plain language explanation a developer can paste into a pull request review.

That fourth verdict is the one I am proudest of. Because it asks the question I wish every DBA kept on a sticky note above their monitor.

Is this index good for the whole system, or is it only good for this one query right now?

Sometimes the mature decision is to do nothing. And doing nothing, in this industry, takes more courage than people realize. It does not show up in a ticket. It does not earn applause. But it protects the system, and protecting the system is the whole job.

Restraint is the most underrated skill in our profession. Nobody gets promoted for the indexes they did not create. But they should.

4. A blocking and deadlock explanation generator

A deadlock graph is an ugly thing. Technical. XML. Hard to explain at 10 AM on a Monday when three people are waiting for certainty you do not yet have. I have stood in those rooms. I have felt that heat behind my ears. I have watched my own voice go a little thin as I tried to explain something complex to people who needed it simple yesterday.

The generator produces something human. Who held the lock. Who was waiting. Which session did what. Which object was involved. How long it lasted. Whether this is a one time event or a pattern. What is safe right now. What should be reviewed later, calmly, when the room is not on fire and nobody is guessing.

The impact is emotional more than technical. The DBA can communicate. The developer hears an explanation without feeling attacked. The manager hears a story instead of XML.

When a manager hears a story, they stop panicking. When they stop panicking, the whole team exhales. That exhale is worth more than most dashboards ever built.

5. A SQL Server health report summarizer

Most teams already have data. The problem is not data. The problem is noise. Health reports are long. They are emailed. They are ignored. They sit in inboxes quietly, like unread letters, and they are only rediscovered after something breaks, usually in the most embarrassing way possible, usually in a postmortem where someone asks, “Wait, did anyone check this report?” and the silence that follows is the real punishment.

The summarizer reads daily health data and produces a one page morning brief with four sections. What changed since yesterday. What needs attention today. What is only informational. What should not wait. Each item links to the underlying evidence, so nothing is hidden. Failed jobs, backup status, disk growth trajectories, Query Store regressions, long running queries, wait trend shifts, CPU and memory pressure, error log anomalies — all condensed into a page a human can actually read with their first cup of coffee.

A twenty page report is not insight. It is homework. And nobody in a busy team has time for homework.

The summarizer protects human attention, which is the scarcest, most overlooked resource in every team I have ever worked with.

6. An AI powered wait statistics interpreter

Wait statistics are one of the most honest things SQL Server gives us. They are also one of the most ignored. Teams say “SQL Server is slow.” But SQL Server is not slow. SQL Server is waiting for something. It is telling you, in its own quiet language, exactly what it is waiting for. The tragedy is that most people never learn to listen.

The interpreter reads the top waits over a chosen window, categorizes each one (CPU, storage, memory, locking, log, network, parallelism), explains what it likely means in the context of this specific workload, flags what is probably harmless, flags what needs attention, and ends with a short list of follow up queries to run to confirm or rule out each hypothesis. PAGEIOLATCH. CXPACKET. CXCONSUMER. ASYNC_NETWORK_IO. WRITELOG. RESOURCE_SEMAPHORE. LCK waits. SOS_SCHEDULER_YIELD. Each of these tells a story if you listen. Each of these is SQL Server whispering a truth that most teams are too busy to hear.

SQL Server is not slow. It is waiting. The question is whether we are mature enough to listen.

I want to sit with that line for a second, because I think it is the quietest thing I believe. Most of our database pain is not mystery. It is unread mail. SQL Server has been writing us letters for years. We just never opened them.

What the savings actually are

I could give you numbers. In one client, three repeating monthly incidents stopped repeating, which, by their own accounting, was worth forty thousand dollars a year in recovered engineering time. I will stand behind that number because I watched them calculate it.

But I no longer lead with money. I used to. I do not anymore. Because in that same client, M took her first real vacation in four years. Two weeks. She turned her laptop off. Her daughter was in every photo. Nothing exploded.

That is the number I care about. I do not know how to put it on an invoice. But anyone who has ever been the person the team cannot function without knows exactly what it is worth.

The fear, named once, properly

I told you at the start I was scared. Let me tell you what happened to the fear.

It did not go away. I want to be honest about that too. Some mornings I still read an announcement and my stomach drops for half a second before my brain catches up. I think that half second is permanent now. I have made peace with it.

But the fear got smaller because I found the part of the work that cannot be copied. And I want to give it to you, in case you need it.

AI can read a plan. It cannot read a room.

Sit with that. Because everything I am about to say lives underneath it.

AI can suggest an index. It cannot decide whether this team, this quarter, with this on call rotation, can absorb the write penalty. AI can explain a deadlock. It cannot tell when a developer is about to quit over how the deadlock is discussed. AI can generate a hypothesis. It cannot carry the scar of the last time that hypothesis was wrong in production at 2 AM with a CFO on the line.

AI does not have scars. You do.

That is not a weakness. That is the whole point. Knowing the answer is cheap. Knowing when the answer is confidently wrong is the job. And AI is very good at being confidently wrong. You cannot automate judgment. You can only earn it, slowly, one incident at a time, in rooms nobody wrote about.

What I am actually proud of

I am not proud because I used AI. That is a small thing. Anyone can use AI. Using AI is not an achievement. It is just pressing buttons.

I am proud because an error became a first response.

A slow query became an evidence path.
An index suggestion became a review.
A deadlock became a readable story.
A health report became a decision.
Wait statistics became something the team could finally listen to.

D and M got coffee before the stand up. M went on vacation.

The output was never the point. The trust was.

That is the work. That is what it was always supposed to be. Quieter rooms. Calmer mornings. Teams that trust each other a little more at the end of the week than they did at the start.

So I will say it again. But I mean something different now.

Relevance is not keeping up with the noise. It is becoming the kind of professional a tired team can exhale around. The kind of person who makes rooms quieter, not louder. The kind of person who leaves teams trusting each other a little more than they did before.

Calm is not a personality trait. It is a practice.

That is what relevance actually is. Not the buzzwords. Not the tools. The calm you bring into the room with you.

So I will ask one more time, the way a friend would ask. Not as a challenge. Not as a threat. Just as one person reaching across the table to another, with both of our coffees cold by now.