For more than 20 years, many small and medium SaaS companies have built products with complicated business logic and a flexible user experience on the .NET stack using an architecture with a shared SQL Server database. This approach has kept the production environment relatively simple.

These companies have new incentives to move away from this architecture because agentic development lands new business rules on the shared database fast enough to painfully cut velocity and add significant risk to deployments.

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.