I ran across a thought-provoking post from Chrissy LeMaire asking if we should reconsider SQL Server HA. The post actually asks if you've considered not using it. The default from Chrissy, for most installations, is to use standalone SQL Servers. This isn't to say she's against HA solutions (FCIs or AGs), but that they often cause problems and might not be needed.

It's an interesting position to consider. For a long time, I avoided SQL Server clusters as they were hard to setup with a lot of complexity, hardware requirements, etc., and didn't really provide enough benefits over using log shipping with a second server for me.  These days I have clients with mostly AGs, and they seem to run fine. That being said, Chrissy notes that after she left a job, a network outages caused a bunch of downtime. I could see there being downtime, as the old database mirroring (and the it-will-never-die replication) needed a working network. If you have network issues, you better know how to manage your HA technology's issues.

I also Brent reposted this on LinkedIn, with some fun comments. There was one great one, which said, "Can confirm. FCI is literally my friend's largest downtime cause." That one got me to stop and think a bit. If I were having stability issues with any of these technologies, I'd certainly look to replace them. I value my time off and my sleep.

I know people who default to using AGs with most servers, mostly to avoid someone calling when a system is down, but to be fair, I also think these are some of the more talented data people I know, so perhaps they can handle minor issues and prevent them from turning into major ones. However, Chrissy brings up a great point. SQL Server HA (or Oracle, PostgreSQL, Linux, etc.) isn't simple. If you have staff turning over, are they qualified to keep things running?

Or do things just happen to run without these people until something breaks?

There is also the RTO issue. If you have a high RTO, like a day or two, is HA worth any amount of effort? Isn't it better to rebuild things and restore? Especially in the cloud, where I might be able to redeploy a new VM/db/etc. and put data in it? Note, I'd want to be sure that I can get to my backups. The SLA on getting older files might be slow, and if it is, I'd want separate backups.

I do think that small to medium companies ought to rely more on backups and tools, like dbatools, to provide the ability to recreate a system. Adding in the complexity of HA certainly shouldn't be the default, especially if you aren't sure the staff will be around for the long term. The caveat with that might be if you use a company like ProcureSQL, StraightPath Solutions, Dallas DBAs or someone else, maybe you don't worry about staff turnover.