I increasingly hear or read the advice to solve problems by querying MCP servers on production databases.

Meanwhile, I’m reading output from an AI agent that tried to use an MCP server of some sort. And the output is full of things that are obviously wrong/false/dangerous.

It’s expensive and dangerous to trust an AI Agent to query production freely, even with read-only access. You have MUCH safer options which will give you better results, both for human employees and AI Agents.

I sometimes joke that I’m a Junior Developer and a Principal Database Administrator, which is why I have a Staff level title. I’m not sure it’s a joke anymore, though.

I’m still an OLTP database specialist, but increasingly I’m also a programmer who commits code in multiple languages. I own pull requests that I ship in a release process, following all the same rules and patterns as other developers. My PRs feature unit tests, integration tests, feature flags, the whole shebang.

Tech roles, including DBA roles, are changing rapidly due to AI coding advances. Don’t use AI to write production SQL code without incredibly heavy review and revisions, but do use it to accelerate shipping your improvements to SQL code.

Adaptive joins let the optimizer choose between a Hash Join and a Nested Loop join at runtime, which can be fantastic for performance when row count estimates are variable. Recently, when Erik Darling taught two days on TSQL at PASS Community Data Summit, a student asked why a query plan where an adaptive join used a Nested Loop at runtime ended up with a large memory grant anyway.

I didn’t remember the answer to this, but the great thing about co-teaching is that Erik did: adaptive joins always start executing as Hash Joins, which means they have to get memory grants upfront. Even if the query ultimately switches to a Nested Loop at runtime, that memory grant was already allocated. This has real implications for memory usage, especially in high-concurrency environments.

I see this pattern repeatedly: a “wide” query that returns many columns and less than 100k rows runs slowly. SQL Server gets slow when it drags large amounts of baggage through the entire query plan, like a solo traveler struggling with massive suitcases in an airport instead of picking them up close to their destination.

SQL Server often minimizes data access by grabbing all the columns it needs early in query execution, then doing joins and filters. This means presentation columns get picked up early.

SQL Server 2025 introduces a new Resource Governor capability to manage tempdb usage, along with making Resource Governor available in Standard Edition.

I wondered: can Resource Governor’s new tempdb feature help contain queries that don’t use temporary tables, but which spill massive amounts of data to tempdb? The docs say yes, but I always like to get hands-on experience when I can.

I’ve got an awful query that spills like a soft-serve machine choosing violence. Let’s test drive the new tempdb governance features in SQL Server 2025.

Triggers can be tricky to observe in SQL Server. When you need to understand exactly what a trigger is doing and what it impacts, Query Store and Extended Events both have something to offer, but using them effectively requires navigating some confusing nuances. Query Store tracks query-level executions aggregated by query_id, but has a habit of generating a lot of query_ids with different context settings for triggers. Extended Events can capture trigger module starts and individual statement completions within triggers.

This post walks through setting up both observation methods on a test trigger, then compares what each one shows. You’ll see how Query Store data gets spread across multiple query_ids and context_settings_id values, a variety of ways to trace triggers in XEvents, and why the numbers don’t always match up exactly between traces and Query Store.