2

We have an Azure SQL Database of size 50GB in the S6 tier. On weekends, the usage is very minimal.

Is it okay to change the tier to S0 every weekend for cost savings, and change back to S6 on Monday?

Are there any other steps to perform prior to the tier change? Do you have any other suggestions?

2

Azure SQL Database is designed to scale up and down based on your workload. I cannot answer your question "is it ok to change the tier to S0 every weekend for cost savings and change back to s6 on Monday" with yes or no.

You also mentioned usage is very minimal. S0 gives you maximum 10 DTU. Do you know for your "very minimal" workload 10 DTU is enough or no. Is your application written to retry disconnected sessions?

From books online:

Existing connections to the database in the original compute instance are dropped. Any new connections are established to the database in the new compute instance. For some combinations of service tier and compute size changes, database files are detached and reattached during the switch. Regardless, the switch can result in a brief service interruption when the database is unavailable generally for less than 30 seconds and often for only a few seconds. If there are long running transactions running when connections are dropped, the duration of this step may take longer in order to recover aborted transactions. Accelerated Database Recovery can reduce the impact from aborting long running transactions.

Few other resources for your third point "any other steps to perform prior tier change and suggestions please".

Not the answer you're looking for? Browse other questions tagged or ask your own question.