Docker

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.

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 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?

Good news for anyone who’s been working around the AVX issue I wrote about in my previous post. Microsoft has fixed it in Cumulative Update 1 (CU1) for SQL Server 2025.

What Changed

Back in November when SQL Server 2025 RTM was released and I upgraded to macOS 26, I ran into an AVX instruction issue that prevented the container from starting on Docker Desktop using Rosetta on Apple Silicon. The container would crash with this error:

Update (February 2, 2026): Microsoft has fixed this issue in SQL Server 2025 CU1. The container now runs successfully on Docker Desktop for macOS without needing OrbStack. See my follow-up post for details.

SQL Server 2025 RTM is here, and if you’re running Docker on macOS Tahoe 26, you might have hit a wall trying to get it running. Here’s what happened when I tried spinning up the latest container image and how I worked around it.

SQL Server 2025 introduces native support for vector data types and external AI models. This opens up new scenarios for semantic search and AI-driven experiences directly in the database. But as with any external service integration, performance and scalability are immediate concerns, especially when generating embeddings at scale.

https://github.com/nocentino/ollama-lb-sql

Problem: Bottlenecks in Embedding Generation

When you call out to an external embedding service from T-SQL via REST over HTTPS, you’re limited by the throughput of that backend. If you’re running a single Ollama instance, you’ll quickly hit a ceiling on how fast you can generate embeddings, especially for large datasets. I recently attended an event and discussed this topic. My first attempt at generating embeddings was for a three-million-row table. I had access to some world-class hardware to generate the embeddings. When I arrived at the lab and initiated the embedding generation process for this dataset, I quickly realized it would take approximately 9 days to complete. Upon closer examination, I found that I was not utilizing the GPUs to their full potential; in fact, I was only using about 15% of one GPU’s capacity. So I started to cook up this concept in my head, and here we are, load balancing embedding generation across multiple instances of ollama to more fully utilize the resources.

Update (February 2026): This post has been updated to reflect the current best practices for monitoring FlashArray using OpenMetrics. Starting with Purity//FA 6.7.x, FlashArray includes a native OpenMetrics exporter, eliminating the need for a separate exporter service/container. The configuration examples below now demonstrate direct-to-array scraping.

This post introduces you to monitoring your Pure Storage FlashArray using OpenMetrics. It shows you how to get started quickly using Docker Compose to monitor your Pure Storage FlashArray environment.

This post shows you how to install containerd as the container runtime in a Kubernetes cluster. I will also cover setting the cgroup driver for containerd to systemd, which is the preferred cgroup driver for Kubernetes.

In Kubernetes version 1.20 Docker was deprecated as a container runtime in a Kubernetes cluster and support was removed in 1.22. Kubernetes 1.26 requires that you use a runtime that conforms with the Container Runtime Interface (CRI). containerd is a CRI-compatible container runtime and is one of the supported options you have as a container runtime in this post-Docker/Kubernetes world. To be clear, you use container images created with Docker in containerd. containerd will start and run the container in your Kubernetes cluster. This post was previously published in February 2021. This is an updated version with the latest installation and configuration steps.

Last week I purchased a shiny new MacBook Air with an M2 processor. After I got all the standard stuff up and running, I set out to learn how to run SQL Server containers on this new hardware. This post shows you how to run SQL Server on Apple Silicon using colima.

Colima is a container runtime that runs a Linux VM on your Mac. This Linux VM runs using the Virtualization framework hypervisor native in MacOS. Your containers will run inside this virtual machine.

Yesterday in this post I described a method to correct permissions when upgrading a SQL Server 2017 container using Data Volumes to 2019’s non-root container on implementations that use the Moby or HyperKit VM. My friend Steve Jones’ on Twitter wondered if you could do this in one step by attaching a shell (bash) in the 2017 container prior to shutdown. Absolutely…let’s walk through that here in this post.  I opted to use an intermediate container in the prior post out of an abundance of caution so that I was not changing permissions on the SQL Server instance directory and all of the data files while they were in use. Technically this is a-ok, but again…just being paranoid there.