Calling him “my developer” doesn’t do justice to Richie’s role here, and he’s really humble, so I wanted to lay out the top 5 reasons you should hire him.

5. He’s got >25 years of lead/architecture experience. When I met him, he’d already been a Principal Engineer, a consultant, a manager, a senior analyst, and more. Calling him “my developer” is awful and I should have stopped it long ago, because he’s an architect first.

4. He’s an extraordinary self-motivated, self-starter. I’m a terrible manager: I just point at the horizon, I describe what the destination will look like, and I dictate very few architecture components if any. He researches everything else, writes a plan, and comes back to me at great points for sanity checks. Then, he builds everything out.

3. He builds really reliable stuff. Right from the get-go, he wanted to do test-driven development, and I got on board. As a result, we’ve been able to build a lot of different tools with a lot of different technologies, some of which soldier on for years unattended. Then, when we want to update something, he’s able to jump back into that untouched code with confidence – stuff he’s long since forgotten – and make changes that he can test, knowing he’s gonna be able to catch problems before they ship.

2. He embraces AI. He was an early adopter of Cursor, and loves trying stuff out to see where it will legitimately help us iterate faster, and where it produces garbage. He loves technology, loves experimenting, and stays up to date.

1. If I could keep him, I would. I’ll be honest, dear reader: if it were up to me, you would never have the chance to poach him from me. I kept him locked up my basement (that’s what we call Florida around here) and didn’t sing his praises over the last decade. I lived in fear that another company would poach him from me, because if it wasn’t for working with Richie, I wouldn’t want to work with anyone else. I honestly wanted to coast out into retirement with Richie, but unfortunately, this whole AI thing means I’m just not comfortable hosting apps with other peoples’ data right now. If it wasn’t for that, you would never get the chance.

But you DO have the chance, so if you have interesting data and architecture roles, you should email him at jorriss@gmail.com. I want him to find the right landing spot at the kind of place that employs people who read this blog.

People like you, dear reader.

Plus I don’t know about you, but I have a heck of a hard time paying attention to recorded videos. I don’t know what it is, but I do a MUCH better job of keeping up when there’s a specific day/time I have to show up, and when there’s a live person on the other side of the screen. I can clear my schedule out to make room for the session, and I love that I can ask them live questions via the chat, and get personalized answers right away.

So let’s do live classes again! But let’s make a few changes:

Live classes will be half-days, Monday-Friday so you can keep the lights on at your day job, keeping your manager happy, and lets you really focus on class while it’s happening. At the end of each day, you have an optional hands-on lab to prove you conquered the lecture’s concepts. The class times in various time zones:

• Eastern: Noon-4PM
• Central: 11AM-3PM
• Pacific: 9AM-1PM
• GMT: 17:00-21:00

It’s now easier to follow along with the labs (and it’s optional.) In the past, I’ve had students restore the database in between each lab. That worked great, but it meant that students couldn’t use Azure SQL DB or Amazon RDS SQL Server because restores weren’t easy on those platforms. Now, we’ll be keeping the clustered indexes the same every time, and creating tables if we need different clustered indexes. That’ll make it easier to reset for each lab by simply running a stored proc to drop nonclustered indexes and extra objects. Here’s how to set up your labs. Or, if you’d like, you can also rent a lab VM from me.

I’ve simplified my class lineup. I’ve got just 6 classes altogether: Index Tuning, Query Tuning, and Server Tuning, with Fundamentals & Mastering versions of each. Rather than having separate classes for things like parameter sniffing, columnstore, and tempdb, I’ve merged those in where appropriate in the other classes. (They’d all changed so much with SQL Server 2022 & 2025 that it made sense to bring ’em directly into the index/query/server classes.)

Here’s the new class lineup.

I’m doing 2 rotations for the 2026 classes: a fall rotation, then a winter one. When you buy a ticket to one of the classes, you get access to all of the dates of that class, so if you miss the first one, if a production emergency pops up, no biggie! Hit the next one instead.

• Fundamentals Week – July 13-17, Nov 2-6 – covering Fundamentals of Index Tuning, Query Tuning, and Server Tuning
• Mastering Index Tuning – Aug 31-Sept 4, Nov 30-Dec 4
• Mastering Query Tuning – Sept 28-Oct 2, Jan 11-15 2027
• Mastering Server Tuning – Oct 19-23, Feb 8-12 2027
• Or grab a Live Class Season Pass for all of the above dates

Each live topic is $1,495 individually, or $4,395 for a Live Class 2026 Season Pass for all of the above. The live tickets include the recordings as well, and after the classes complete, the recordings will be $795 for each of the above. (Obviously, the recordings won’t be available until after the classes finish, heh.)

Buy before July 10, and take 50% off Fundamentals Week or the Live Class Season Pass! That’s $747.50 for Fundamentals Week, or $2197.50 to attend everything, plus access to the recordings in 2026.

I wanna make it as easy as possible for you to get signed up, so I’ve put together a few sample emails that you can copy/paste in to send to your manager, accounting, HR, or whoever else approves your training funds:

• Database administrator
• Database administrator having a really bad day
• Developer without a full time DBA at the company
• Manager facing big migration and upgrade projects
• Manager picking a new lead SQL person
• Manager tired of firefighting performance emergencies
• Manager with a training budget
• Manager worried about cloud bills
• Manager who’s been mandated to implement & spend money on AI
• Manager who lost a poker game

If you have another situation where you need a letter, feel free to leave a comment below and I’ll see what ChatGPT can come up with.

See you in the live online classes!

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!