Why Are Y’all Changing the Compat Levels on Master?
22 Comments
One of the things I love about SQL ConstantCare® (which happens to be free this month, by the way) is that I can keep in touch with what y’all are actually doing on your production servers.
Today’s lesson was a complete shocker to me: some of y’all are changing the compatibility level on the master database.
Normally, when you install SQL Server, the master database gets a compatibility level that matches your SQL Server version. If you’re on SQL Server 2019, for example, the master database will be compat level 150, which is 2019.
But there are a surprising number of users – like, over 20% of the population overall – who have changed the master database to be an older compatibility level. For example, we’ve got one user with several SQL Server 2022 instances, but they’ve chosen to set the master database to compat level 100 – that’s SQL Server 2008!
So I’m curious: if you’re one of those people who set the master database’s compat level to an older version … why? Are you running end user workloads in the master database, perhaps? Let me know in the comments, and it’s a judgment-free zone. I’m sure there are good reasons, I just … don’t know what they are.
Update 2023-06-16: Sounds like it’s in-place upgrades. I’m so saddened by this because I’ve told y’all not to do that, but in retrospect, I don’t think I’ve said it enough. I wrote that 8 years ago, and there are obviously a lot of new readers that have come in since then, and we should talk about it again. Noted.






If your company is hiring, leave a comment. The rules:
I’ve never attended Build in person before because the data part of the event tends to be fairly thin, and the releases for Azure SQL DB and SQL Server aren’t usually tied to Build’s dates. This year, it’s a hybrid event, both in-person in Seattle and online.
































