AzureAzure Data Platform

Changing Service tiers? Do you need downtime?

Do you need downtime for changing Service tiers on SQL Database and SQL managed Instances?

Cloud has changed Infrastructure maintenance drastically; scaling up/down with the click of a button (or programmatically) is one of the major USP of using the cloud. You no longer have to wait for budget approvals, Quotation process and provisioning, & there is no need to incur CAPEX (capital expenditure) on purchasing the Hardware. The mere ability to dynamically scale your servers is more than enough for most small businesses to move to the cloud. 

Now the question arises, does changing Service tiers needs downtime? Before we conclude anything, let’s first understand what happens when you scale up\down your service tier. 

What happens under the hood?

Changing the service tier with or without the performance level of a database creates a replica of the original database at the new performance level; and then switches connections over to the new replica. 

So, this still needs some downtime. You can’t switch connections without downtime. No data gets lost in this process, but during the brief moment when we switch over to the new replica, connections to the database are disabled, and the in-flight transactions will rollback. This window varies but is on average under 4 seconds, and in more than 99% of cases is less than 30 seconds. And if there are large numbers of in-flight transactions, this window may get longer. But the bottom of the fact is “You need DOWNTIME while changing Service tiers”. 

I’ve seen websites going down or critical applications facing downtime just because they miss to read in-between the fine lines & don’t test it. Make sure you also implement a re-try logic into your Application so that the client Connections can connect automatically after this short downtime & it happens gracefully without those ugly errors.

I hope this helps you to make a well-informed decision. 

Do subscribe to our blog for the latest updates.