I’m excited to announce the release of a new open-source project that fully automates HammerDB benchmarking for SQL Server using Docker. If you’ve ever needed to run TPC-C or TPC-H benchmarks multiple times, you know how time-consuming the manual setup can be. This project removes the hassle and gets you up and running a single command: ./loadtest.sh.

Updated for HammerDB 6.0

What’s new since I first wrote this:

• Every run writes a JSON report and HTML charts, not just console output.
• Response times are broken out per stored procedure, with p99 through p25.
• You can tag runs with a PROFILE_ID and diff two configurations directly.
• loadtest.sh runs through the whole lifecycle of a load test.

Why I Built This

In my work, I frequently benchmark SQL Server configurations, whether I’m comparing versions, testing new hardware, or validating performance tuning changes. Setting up HammerDB manually each time became a significant time bottleneck (see what I did there! ;). I needed an automated solution that would work consistently across different environments and reduce the time required to get test results.

Ten years ago today, I filmed a Pluralsight Play by Play on open source PowerShell. I was standing between Jason Helmick and Jeffrey Snover, trying very hard not to look like the guy who had learned PowerShell six weeks earlier. I later wrote about that experience, but that day was the beginning of a much longer story.

Yesterday I gave a talk for MSSQLTips called “Building a DBA Agent for Your SQL Server Estate”. I’ll drop the recording into this post once it’s published. What I want to do here is pull the whole thing together in writing: the demos, what I actually ran against a live SQL Server estate, and the argument I’m making when I say an AI agent can be trusted near production.

If you’ve been following along, this is the third post in what’s turned into a series. In Giving AI Agents Visibility Into SQL Server with MCP, I built sql-mcp-server, a custom MCP server that gives an agent real DMV access. I said at the end of that post that skill files were coming in a follow-up also in Using Claude Code as a Database SRE Agent, I showed a skill file catching a silently unprotected DR instance against the Everpure Fusion fleet API and how to build compliance and observability reports quickly. So here we are.

I’ve been running this blog on Hugo for a long time, and like most blogs with real history, it’s accumulated some tech debt. Some of it is my own fault. This blog started on WordPress, where it ran for seven years, and I migrated it to Hugo back in 2021. That migration exported those seven years of posts straight from WordPress’s database into raw Markdown, HTML tags, inline styles, and all. I am not a good HTML programmer, and it showed. Broken tags, stray   entities, image markup that only sort of worked, all of it scattered across dozens of WordPress migrated posts.

I’ve been rebuilding my three-site SQL Server demo lab, and I ran into something I’ve wanted for a long time. If you’ve ever designed a SQL Server environment on ActiveCluster, you know the pattern: two FlashArrays running a synchronously replicated pod for zero RPO between sites, and a third array somewhere else for a longer retention, disaster recovery copy. The problem was that you couldn’t get the data to that third array directly from the pod. Protection groups inside a stretched pod simply couldn’t have an array target.

It’s that time of year again! EightKB is back on August 20th at 13:00 UTC, and registration is open right now. It’s completely free. No catch, just a full day of the deepest SQL Server content you’ll find anywhere on the internet.

Mark, Andrew, and I have been putting this event on since 2020, and this year’s lineup might be the best one yet. All sessions are 400-level. That’s by design. We built EightKB specifically to fill the gap for serious internals content in the SQL Server community.

Here’s the scenario: one of my SQL Server instances migrated to the DR array. The VM moved, the old volumes were destroyed, and nobody created a Protection Group on the destination. There were no alerts. Nothing failed.

The DR environment just quietly had no data protection. No snapshots, no replication. We’d have had no idea until we needed to recover. Ok, well this was in my lab, but this could really happen in the real world.

I’m honored to announce that I’ve been renewed as a Microsoft MVP for the tenth consecutive year, recognized in the Azure SQL and SQL Server technical areas under Data Platform. Ten years. I honestly didn’t see that coming when I set a five-year goal back in 2016.

Ten Years

I want to stop and acknowledge that milestone for a moment. When I first earned this award in 2017, I was deep in Availability Groups and SQL Server internals. Since then, the journey has taken me through SQL Server on Linux, containers, Kubernetes, storage integrations, and now AI-integrated SQL Server 2025. The platform has transformed dramatically, and I’ve had a front-row seat for all of it.

I’ve been working on a project that combines two things I spend a lot of time with: MongoDB sharded clusters and Everpure FlashArrays. The goal is a production-grade backup and restore solution that avoids mongodump, doesn’t require fsyncLock, and scales across as many arrays as your cluster needs without any code changes. In this post I’m walking through the complete workflow (snapshot, disaster simulation, restore, and verification) running against a real 3-node sharded cluster with data spread across 3 independent FlashArrays, all managed through a single Everpure Fusion gateway connection.

I’ve been thinking a lot lately about what it actually takes to make an AI agent genuinely useful for database work, both for administration and for application access to the data tier. Writing the T-SQL code is the easy part. A coding assistant can do that out of the box. The hard part is giving it visibility into a running SQL Server: which sessions are blocked right now, where the wait stats are pointing, which indexes the optimizer is begging for. Without that, the agent is just guessing. With application access, an agent can propose how things should work, but what if we had tools that added context describing the agent database’s schema and what the entities actually mean to the application when interacting with the database agentically?