At the start of November sqldba.blog had 587 posts on it. I’ve been at it on and off for about eight years, and it’s only now, with the help, that I’ve got something into shape I’m actually proud of.
It’s my SQL Server blog, written for the DBA who is in the middle of a problem and needs the next thing to check. This is about how much it has turned into, and how it got built, which has been me and an AI, Claude, working on it together.
The Size of It
The Wait Types Library is the biggest part, 236 pages, each one explaining a wait type, what it means and whether it is worth worrying about. There are 154 DBA Scripts posts, one for each script, showing what it returns when you run it. The error library covers 92 SQL Server errors, and the whole site is arranged into 14 pillars across 8 areas so a reader can find their way from a symptom to a fix. Over 300 posts went up in July alone, when the wait types library and the script series went live.
Behind the blog is dba-tools, the free toolkit on GitHub. It has 195 SQL scripts now, 673 automated tests that all pass, and 444 commits since the first push on 28 May. Every script post on the blog is built on one of those scripts, so when a script gets fixed the post gets fixed with it. The MCP server that lets an AI assistant look things up in it is its own story.
From Manual to Directing
I started moving the SQL Server content from peter-whyte.com to sqldba.blog at the start of this year, and at first it was manual. Then my use of AI snowballed through the year, and I was able to tackle it differently. AI can help create the scripts and stage everything, work that used to take many hours. I’m now able to learn new features as I go, while AI does the heavy lifting.
How the Work Splits
I’m the director and Claude is the advisor. I pick the work, Claude drafts it, tests the scripts against a SQL Server 2025 instance I run at home, and builds whatever tooling the job needs, including a staging copy of the whole site so nothing goes live before I’ve seen it. I manually test everything we do. That’s the human pass, and it’s how there comes to be evidence and a screenshot behind a post. That’s the standard for every post, and I’m still working through bringing the older ones up to it.
At a high level, this is how a change gets to the live site:
- Staging firstEverything goes onto a private copy of the site, never straight to live.
- ChecksScripts run against my lab and the automated tests, and each page goes through a checklist before it reaches me.
- My testI run it myself and take the screenshot.
- My approvalI read it on staging, and nothing goes live until I’ve said so.
- My pushClaude prepares the update and does a dry run, I run it, and then the live page gets checked the way a visitor would see it.
- Live on sqldba.blog
That split has moved over time. Since 1 November I only read the content and the screenshots on an update. Minor fixes like alt text, spacing and headings are approved automatically now, because I can’t be checking every minor fix. The ones that matter tend to be the ones you only see by looking at the page. In August I opened one wait type page and the library banner was printed twice, and that turned out to be on 234 pages. Nothing automated had caught it.
The Effort
It’s hard to put a number on effort, but some things can be counted. Every working session ends with a written handover so the next one can pick up where we left off, and there are 36 of those in the last fortnight alone. On 31 October we updated 33 posts on the live site in one day, and on 20 October it was 46. The private notes where the planning, reviews and decisions live have 2,161 commits since 5 July. All of that sits around my day job, and life and responsibilities.
The Setback
Not all of it went well. In July I changed the site’s URL structure along with a big batch of other changes, and Bing traffic dropped hard. Bing clicks on a weekday averaged 87.7 in June and 52.3 in July, about 40% down, and it took around two months to come back. By September it was averaging 119.2 a weekday, higher than before the change. Not all of the drop was down to me, Bing was already sliding through June and my old site fell over the same weeks, but since then everything is done one page at a time, never across the whole site at once. In August the host was also down for over eight hours on the same day we were shipping a redesign, which was a crazy day.
Where It Is Now
October was the best month so far, 4,149 clicks from search, and I’ve put the full numbers in the latest traffic update. Ads have been on since 12 August and have earned next to nothing so far. It’s a waiting game now, for search engines to trust a site that’s new to them. On 8 October I shared it on Facebook for the first time, once I’d got the share card looking right.
My caption was “For anyone who likes SQL”, which undersold it a bit. It’s at the stage where I’ve built something I’m proud of, and I want to look after it well. I’m paying for a bigger AI plan than I ever expected to, as a bet that it pays back. You really have to believe in the idea to make it happen. I work hard and I’m consistent, and I lead with passion and whatever my gut says, which is how most of this got built.
What Comes Next
First, the finishing. Every existing post gets brought up to the standard, with my own screenshots from the lab, before new posts take the focus again. After that it goes back to a new post most days, written for the DBA in the middle of a problem, holding an error number or a wait type.
I’m also writing more about the new things in SQL Server and SSMS as they land, tested in my lab first, like the Copilot features in SSMS 22. The scripts keep growing in dba-tools, and the AI side of it, an assistant that can look up the site and run a health check, is the part I think sets it apart.
The bigger bets are still ahead, maybe a WordPress plugin built from the code blocks this site runs on. Everything is built so it would keep running without AI, but in reality I’ll be using it as much as I can.
Leave a Reply