Here’s what we covered:

• 00:00 Start
• 02:29 No Lying: Be real — has anyone actually gotten meaningful value out of In-Memory OLTP
• 04:08 Idaho: When is it responsible to use a query hint instead of trying to make the optimizer choose the “right” plan on its own?
• 05:59 Senior or Junior: At what point is someone actually a “Senior DBA” — years of experience, outage scars, mentoring others, or something else?
• 07:48 Casey: Does consulting make you sharper because you see more environments, or shallower because you rarely live with the long-term consequences?
• 09:05 Justin Case: Is it finally time to admit that stored procedures are an outdated way to manage business logic, and we should be moving it all to the application layer?
• 10:44 RoJo: Can SQL be used to store application secrets instead of Azure keyvault securely? Seems like a great place and much cleaner than reading from vault. Any drawbacks?
• 11:28 Faint Smell of Greggs: I’m splitting up a 20 TB database across at two servers, but the split is such that a foreign key relationship will have to go across the servers. If I can’t get rid of the foreign key, what options remain?

Dev-Prod Demon Hunters:
Finding the Real Cause of Production Slowness

Production is slow. Development is fast. The same query runs in both. Somewhere between the two, a performance demon is hiding—and this session is about hunting it down.

Inspired by Brent Ozar’s love of the K-Pop Demon Hunters theme song, this class is delivered almost entirely as live demos, not slides. Brent Ozar will run real queries against two environments labeled “dev” and “prod,” then work through them exactly the way an experienced DBA would in the real world: comparing server settings, analyzing execution plans, and uncovering the subtle differences that led SQL Server to make different decisions. Each “hunt” reveals another demon—statistics, configuration, data distribution, or plan choice—and shows how easily a test environment can lie.

Along the way, Brent will demonstrate practical techniques you can use immediately: running sp_Blitz to surface meaningful environment differences, comparing execution plans to understand *why* SQL Server behaved differently, and making targeted changes to development so it better reflects production reality. By the end, you’ll understand how to stop guessing, stop blaming the engine, and follow the clues that lead to the truth—because when dev and prod finally move in sync, that’s when performance goes golden.

3 things you’ll get out of this session

• Discover what caused query plans to vary from production
• Learn how to quickly assess environment differences that would cause query plan changes
• Understand how to change dev to more closely match prod

Pre-requisites: You should already be comfortable writing queries, reading execution plans, and using the First Responder Kit to gather data about your server’s wait stats and health.

Registration is open now and attendees will get a free year of my Recorded Class Season Pass: Fundamentals. See you in Seattle!

Richie Rump did an amazing job of building SQL ConstantCare out in the years since, building a solution that was rock-solid and scaled well to terabytes of monitoring data. Every day, we sent thousands of emails for SQL Servers around the world.

This month, we shut off sales and began decommissioning it. Here’s why.

AI is making it terrifying to host apps. It seems like every week, there’s a new AI-discovered exploit that blows new holes in the defenses of major companies, like the recent widespread npm compromise at Redhat. Companies are up against sophisticated, coordinated threats that strike against the very foundations of stuff we build with and atop. I think we’re going to be in for a very rough decade of security breaches, and in this timeline, I don’t really wanna host any repositories with diagnostic data from your database servers.

The world didn’t move to cloud the way I expected. I figured it was going to take 10 years, but like I wrote in my 2018 predictions for 2026, I figured that your default new database would be in a cloud platform-as-a-service database provider like Azure SQL DB or Amazon RDS. That simply hasn’t come true, and in a really weird twist, entire countries are now shifting away from the cloud due to political issues. When I look into the future right now, I think most small to midsize companies will be even less likely to move to cloud-based data hosting and processing.

We never really got the adoption we wanted. It was good enough to break even – even with a free tier of the product – and in the past, breaking even was fine. However, looking ahead to the future, I have my doubts about that financial situation continuing. I think cloud-based monitoring tool adoption is going to decrease, while the AI-driven security risks simultaneously increase, and suddenly even the prospect of breaking even isn’t appealing anymore.

I’m absolutely going to miss it. When I had spare time, It was fun and rewarding to open up my Power BI monitoring console, start poking around in the worst-performing SQL Servers, and send personalized, in-depth advice to customers and make a real difference in a matter of minutes.

So I’m also letting Richie go.

Richie and I have worked together here for over a decade, and he’s built a ton of stuff that gets used by database pros around the world every day: SQL ConstantCare, PollGab, the Consultant Toolkit, PasteThePlan, StatisticsParser, and the new StatisticsParser SSMS extension, plus a lot more stuff behind the scenes here.

For all these years, he’s been the perfect combination of architect, builder, tester, and troubleshooter. He’s also a ton of fun to work with! I would absolutely love to keep working with him, but as a tiny boutique database consulting firm, I don’t wanna be in the app business for the next few years. I’m not replacing him with AI – I couldn’t possibly, because he’s so damn good. This also means I’ve stopped sales on the Consultant Toolkit, and existing customers will get updates for the next year.

If you’re looking for an absolute top-notch data professional, I highly, highly recommend getting in touch with Richie at jorriss@gmail.com.

(Update: this has no impact on the First Responder Kit. I’ll continue shipping sp_Blitz and friends. Those are T-SQL, and I’ve always maintained those myself.)

• 00:00 Start
• 01:40 DbaMan: You have been reulctant to turn on ADR. It is required for optimized locing in SQL Server 2025. What is your view of ADR + Optimized locking? Is it almost an automatic yes, or should it only be enabled if we have BIG problems with locking/blocking?
• 05:32 TeaEarlGrayHot: Why is the size of the persistent version store in SQL with optimized locking a concern while in postgres and mysql that store their persistent version store in table, it is not? Is the assumption that postgres and mysql are less likely to use HA?
• 07:27 Will: We have a primary mssql enterprise cluster (2 vms) and a DR cluster (2 vms). We use one always on AG on the primary cluster, and another for the DR cluster. We connect the two AGs via a DAG. Is this a typical SQL DR setup, or is there a better way to set up a DR environment?
• 11:34 MyTeaGotCold: Have you seen anyone regret choosing Azure Hyperscale rather than another Azure PaaS? Microsoft seems to push it very hard.
• 12:25 Jeffry Altamar: What is your advice for removing a massive 4TB table from a live database: should I delete records in chunks and then drop it, or simply drop the table with no previous steps? What is safest?
• 13:47 Elwood Blues: How much AI should a prospective SQL 2025 DBA know if the database is using the new vector type?
• 15:33 Bandu: What’s your opinion of AI written books? Should they be flagged as AI witten? Would you ever purchase one?