"At best it would crash" is not a phrase I'd like to have to use as a data professional. That's a quote from an article that the Azure team wrote about hot patching SQL Server. While this sounds very scary, it's actually something being used now to patch the SQL Server code running Azure SQL Database.
Years ago I read a book where the hero was a programmer that had to alter and hack into live code on a mainframe, making changes to thwart the villains. It was a neat concept, and certainly daunting. As someone that had to write assembly code at one point, I had trouble keeping track of instructions when I could map them out on paper. Doing this on live code would be very scary.
The SQL Server code is not being changed live by a human, but code is being patched without stopping the sqlsrvr.exe process in Azure. There is a blog on the hot patching process, which I appreciate, though I'm not completely sure I get the minute technical details. Still, it's an impressive feat of engineering to me, and this does make me wonder to what extent platform engineers might structure their code to allow more of this in the future.
Deploying changes is already a challenge for many of us with database code. Making changes, evolving our schema and adding functionality without downtime or excessive blocking is a challenge. Many customers that look to move to a database DevOps software development process often assume that our tools will just do this for them. They won't, because any DevOps tools that help with automation don't magically get around the limitations and restrictions that Microsoft has built into the platform.
Making changes in real time, without interrupting workloads involve some engineering challenges, but whether at the SQL Server platform level or the database code level, they are possible. It takes some work, some flexibility, and more importantly, some understanding of how changes can be made and the patterns that enable uninterrupted changes. There is often a space and time trade-off, and certainly no magic, though to our customers, it might appear that way if we do our jobs well.
