This week, I am honored to be speaking at the most excellent 8KB conference. If you aren’t aware of this conference, it’s ran by several members of the SQL Community. It is designed to be a deep dive internals conference. While it started out as internals of SQL Server, over the years it has grown and expanded into other concepts so if you like nerding out to technology, this is a conference that you do not want to miss.

As I’ve been spending more time working with Contained Availability Groups (CAGs), I’ve run into something that I think is an issue as they become more prevelant in the wild. To be honest, I do not have a lot of clients running CAG’s so I do not know how wide spread they might be but this is something I noticed.

To be blunt, it’s an SSMS problem. Specifically, there is no obvious visual indicator that tells me whether I’m connected to a SQL Server instance or connected to a Contained Availability Group. The icons within SSMS are the same regardless of which context you are connected to.

Contained availability groups solve some real operational problems, especially around logins, jobs, permissions, and supporting metadata. They can reduce drift between replicas and make failover cleaner.

That does not mean they are magic.

In the first post, I introduced contained availability groups and how they bring contained versions of master and msdb along with the Availability Group. That matters because many applications depend on more than just user databases.

Two of the biggest wins are SQL Agent jobs and security objects.

Availability Groups have been one of the best high availability and disaster recovery options in SQL Server for a long time. They let us move a group of user databases together, keep replicas synchronized, offload some read-only workloads, and give applications a listener instead of a single server name.

That works great until the application needs more than just the user databases.

Every now and then, you run into a situation where you just need to know one thing:

What is my public IP address right now?

Seems simple—but when you need to automate it (scripts, monitoring, firewall updates, etc.), it’s not always as straightforward as opening a browser and Googling “what’s my IP.”

I ran into this issue at a client who had two different ISP providing internet services to their office. This means that when pushing SQL Server backups directly to an Azure blob storage account, I had to dynamically determine what public IP address traffic was traversing at the current moment in time.

For years, my website lived on a fairly typical stack—WordPress hosted through GoDaddy. It worked. It was easy. And like most things that “just work,” I didn’t think too hard about it… until I did.

At some point, I started asking a simple question: Why am I paying this much for something that gives me this much grief?

That question turned into a full migration—away from WordPress and into a static site powered by Hugo and hosted on Azure Static Web Apps. I’ll tell you why in a moment.

If you are planning to deploy Amazon RDS for SQL Server Developer Edition, one detail is easy to miss: this is not a license-included offering. You are expected to bring your own SQL Server Developer licensing entitlement when you create the instance. This little nugget of information came as a shock when I tried to build a Developer RDS instance.

This matters because many teams probably assume “Developer Edition” means “free everywhere.” The software edition itself is free from Microsoft for development and test use, but that does not mean AWS is packaging it as a standard license-included RDS option.

I firmly believe that no single individual will ever know everything about SQL Server. I’m constantly learning—often even in areas where I once felt confident in my expertise. Recently, I was discussing accelerated database recovery (ADR) with fellow MVP Ben Miller, specifically the cleaner thread pool introduced in SQL Server 2022.

If you’ve used Azure SQL Managed Instance General Purpose, you know the drill: to boost memory or I/O, you had to scale the whole instance, paying for extra CPU you might not need—and hoping the upgrade fixed the bottleneck. It worked but wasn’t elegant and could be slow or awkward. Scaling sometimes took hours when time was of the essence. The Next-Gen Azure SQL Managed Instance marks a major shift from the old model. It was way overdue.