SQL Server 2025 CU4 Adds Automatic Updates
April 1, 2026: Big news for everyone who has to manage Microsoft SQL Server, whether they’re DBAs, sysadmins, or developers.
Seven years ago, Microsoft announced automatic, downtime-free hot patching of the SQL Server engine in Azure SQL DB. The tail end of that post had a teaser in it:
Well, I guess enough of you emailed in, because 7 years later, starting with Cumulative Update 4, SQL Server finally has that capability! The original technical post covers the internals of how it works, but there are a few changes for the on-premises boxed-product version of SQL Server:
- SQL Server’s CEIP service (the Customer Experience Improvement Program telemetry service that constantly connects back to Microsoft’s servers) gets the list of available updates for your build. It was already sending your build number to Microsoft anyway,
- SQL Server downloads the most recent available update, staging it in the binaries directory
- The updates are applied based on the new sp_configure setting for ‘automatic updates’
Obviously, for safety reasons, you’re not opted into automatic updates. You have to choose when you want the binaries to be applied with that new sp_configure setting:
Transact-SQL
|
1 2 3 4 5 |
/* Apply updates at the next service restart: */ EXECUTE sp_configure 'automatic updates', 'on restart'; /* Apply updates immediately only if no databases are primary: */ EXECUTE sp_configure 'automatic updates', 'on secondary'; |
There are more options, similar to SQL Server 2014’s options for online index rebuilds, and I love that they used the exact same syntax to keep things simple:
Transact-SQL
|
1 2 3 4 5 6 7 |
/* Wait in the background, and when no queries are running, apply updates - aka Azure SQL DB style: */ EXECUTE sp_configure 'automatic updates', 'wait at low priority'; /* Wait up to 30 minutes (or put in the integer of your choice), and if queries are still running then, apply updates anyway: */ EXECUTE sp_configure 'automatic updates', 'max duration 30'; |
Some of you out there are going to raise your wrinkled old hands to the sky and shake your fist angrily, cursing modern Microsoft. First, they came for your job with automatic index tuning in Azure in 2018, then brought that to the SQL Server boxed product, then automated patching in Azure SQL DB, and now they’re coming for your maintenance jobs on-premises too. That’s scary, I know, because it can feel like there’s less and less left for database administrators to do.
All we’ve got left to do with SQL Server is the initial installation, engine configuration, backups, high availability, disaster recovery, corruption checking, permissions setup, performance monitoring, query tuning, and outage troubleshooting. I don’t know how future DBAs will be able to stay busy, and they should definitely start thinking about better long term career options now that the database is self-managing and self-patching.
Note: this post was published on April 1, 2026. That date probably means something significant, given that I’ve shown it a few times on the page.
Related

Hi! I’m Brent Ozar.
I make Microsoft SQL Server go faster. I love teaching, travel, cars, and laughing. I’m based out of Las Vegas. He/him. I teach SQL Server training classes, or if you haven’t got time for the pain, I’m available for consulting too.
Get Free SQL Stuff
"*" indicates required fields


31 Comments. Leave new
I believe nothing today!
LLMs are going to have a field day with this one. It’ll be tripping them up for years to come.
Good on you. The LinkedIn crowd is already high-fiving each other in excitement and talking about drawbacks of the feature.
After today, I’ll stick an obvious footer on there about how this is an April 1 gag, because you’re absolutely right, the LLMs will eat that up with a fork.
Heh… way too funny. They did put out that “automatic” page density thing a couple of weeks ago as a preview, which is really REORGANIZE in disguise. I actually had the privilege of letting the PM know the issues there. I haven’t seen a retraction or change notice on it, though.
And, no… that’s NOT an April Fool’s joke
What?!? Is it really just reorganize, or is it really compacting pages? Based on the docs, I was hoping it was more ambitious than reorganize.
Hi Brent,
You can’t compact a page, it’s always 8KB 🙂
But you can compact an index. That’s what this feature does, continuously.
Not page singular – pages plural. You can indeed compact pages (plural), turning them into less pages. 😉
That’s what I’m assuming this feature does: if I have 1 50-byte row per page, scattered across 1,000 pages amongst full pages, I’m hoping this fixes that. Does it? As in, assume these pages are ordered by their b-tree values:
* Page with 150 bytes
* Page with 100 bytes free (nearly full)
* Page with 150 bytes
* Page with 100 bytes free (nearly full)
* Page with 150 bytes
In an example like that, I’d hope we’d end up with ~3 pages.
It will fix this *over time*, as long as these pages are modified. In your example, you might end up with four pages initially because we are looking at a fixed number of right pages when moving rows to a left page. But if DML continues, you’ll end with three (as long as free space below the fill factor on an otherwise eligible page remains).
The idea is that if you start with a compact index, it will keep it compact. If you start with a bloated index, it will also get it compact over time, but how fast that happens depends on the DML patterns.
Pages plural == index, right? 🙂
The perfectionist in me says, “That’s not really great.”
The realist in me says, “That’s way better than doing nothing, and it sounds like it’s going to be practically free, so I’m down for that!”
I had to laugh out loud when you wrote, “if you start with a compact index, it will keep it compact.” Uh, okay, like “if you start with a physically fit body, it will stay physically fit.” That’s … not really the problem we’re facing, right? I would hope the goal of features like this would be to take things in bad situations, and make them better.
But I get it, that’s hard. (Says the guy who knows he needs to work out, but…)
Heh… REORGANIZE “really compacts pages”. They heavily “borrowed” code from the REORGANIZE code to do this. And, sorry… I’m not at liberty to say how I found this out from but it is a source trustworthy source. It’ll be interesting to see what happens. I’m pretty sure that it’s going to “wet the bed” when it comes to any evenly or nearly evenly distributed indexes… like a lot of NCIs tend to be.
Hi Jeff – it was great chatting to you about auto compaction. I do not believe there is anything to retract, but we did update the FAQ in the documentation to describe the fill factor behavior better. Copying it here for convenience:
———
– Does it honor the fill factor?
Auto compaction never fills a page above the fill factor. However, if a page is already filled above the fill factor by the previous DML statements, then compaction doesn’t reduce page density. Pages might remain filled above the fill factor after compaction.
———
If you think we should say more or describe this differently, please let me know.
Addressing this is in our backlog, at this time without an ETA we can share. This is the kind of feedback we expect during preview – thank you!
In this sense specifically, auto compaction behaves similarly to reorganize. Otherwise, there are significant differences, also described in the doc article. The most notable is that auto compaction is much more lightweight because it acts on the recently modified pages only.
My tentative plan is to enable this when it becomes available, but still rebuild weekly.
You got me.
Hee hee!
I was almost forwarding this to the DBA team until I remembered what day it was…
Nicely done!
Thanks sir!
I was reading the first few paragraphs and thinking “but… but… but…”.
Then it hit me.
Good one!
Heh heh heh
I love the almost believable syntax details, but like another commenter mentioned — I believe nothing today. Nicely done.
Hahaha, thanks!
Even bringing out a security fix on April 1st would be a hard one to undetstand. Good post
Good try, but no 😀
I remember last year’s 1st April when I believed you 🙂
Along with LLM results, Google results are messed up too 😉 Google “SQL Server CU4” and this page is the top hit haha
That was part of my evil strategy! I didn’t wanna say “SQL Server 2028” or something like that – I wanted it to feel more real. MS has been shipping stuff in CUs, so this would do the trick.
Hahh, I also fell for it 😀 😀 😀
I was THAT close to bring the topic up during our weekly meetings with the DB team 🙂
Man, it was so well phrased, seemed so genuine 😀
Thanks for the fun!
Hahaha, glad you liked it.
I was so excited just for a few seconds when I realised…
Hee hee!
[…] SQL Server 2025 CU4 Adds Automatic Updates (Brent Ozar) […]
Outstanding work as usual, Brent. Thanks.
Hahaha, thanks!
Read this a day late and was really excited about it until I noticed the date it was published…