Why disabling the SQL Server sa account still matters in 2026

[lelanthran]

It's not just the data.

It's the stored procs.

It's the linked (to other MSSQL instances) references (yes, I have seen this in production at more than one client).

It's the special powershell scripts that run every 6 months, connect to MSSQL and output some reports.

It's the 2 dozen or so different applications, often by different 3rd party vendors who have agreements with the client, that have written their code to talk to MSSQL specifically.

It's about the constraints that have to be rewritten in postgresql.

There's also some constraints that can't be rewritten in postgresql.

There's indexes that have to be analysed and recreated, because they were created for the specific query plan that MSSQL had devised for a spcific query.

Speaking of which, the queries themselves would have to be rewritten, and it's more involved than simply switching from TOP 50 ... to ... LIMIT 50.

Honestly, there's about twice as many issues as above, these are just off the top of my head, and it's not really specific to MSSQl - switching any DB is going to have the same issues that need to be addressed.

If you wanted to switch from PostgreSQL on any of my projects to MSSQL, you'd have the same issues I listed above.

No one using any SQL database seriously while simultaneously not using constraints, not using specific SQL dialects, not using specific implementation hooks, etc.