Azure SQL Database automatically reverting to previous pricing tier and restoring after deletion

Hi Abuzar Khan,

Thank you for the detailed description — I can understand why this behavior is confusing.

From what you’ve described, this is not expected behavior from Azure SQL Database itself. Azure does not automatically change pricing tiers or restore a deleted database without an explicit action. This typically indicates that some form of automation or governance control is acting on the resource.

There are a few common scenarios to consider:

Azure Policy enforcement If a policy is assigned with effects like DeployIfNotExists or Modify, it can automatically remediate resources that drift from the expected configuration (for example, reverting the pricing tier).

Infrastructure-as-Code (ARM/Bicep/Terraform) or CI/CD pipelines If your database is defined in a template and deployed on a schedule or trigger, any manual changes (like scaling down or deleting) can be overwritten by the next deployment.

Automation (Runbooks, Azure Functions, Logic Apps) Scripts running on a schedule may be enforcing a desired state and recreating or resizing the database.

Geo-replication or Failover Groups If the database is part of a failover group, deleting the primary can result in a failover, making the secondary appear as if the database was “restored.”

It’s also important to note that automated backups do not restore a database by themselves — a restore operation must always be explicitly triggered by a user or process.

The most effective way to identify the root cause is:

Activity Log (Azure Monitor) Review operations like Microsoft.Sql/servers/databases/write and delete to see who or what initiated the action (user, service principal, or managed identity).

Resource Group → Deployments Check for any template deployments recreating the database.

Azure Policy → Compliance Look for policies enforcing SQL configuration.

Automation Accounts / Functions Review any scheduled jobs or triggers targeting this resource.

Based on your scenario, the behavior is almost certainly being triggered by an automated process (policy, deployment, or script) rather than the Azure platform itself.

The key step is to check the Activity Log and identify the “Caller” responsible for the scale or restore operation. Once identified, you can trace it back to the corresponding policy, pipeline, or automation and adjust or disable it.

Microsoft Reference Links:

• https://learn.microsoft.com/azure/governance/policy/concepts/effects#deployifnotexists
• https://learn.microsoft.com/azure/azure-resource-manager/templates/deployment-modes
• https://learn.microsoft.com/azure/azure-sql/database/auto-failover-group-overview
• https://learn.microsoft.com/azure/azure-sql/database/recovery-using-backups
• https://learn.microsoft.com/azure/azure-monitor/essentials/activity-log
• https://learn.microsoft.com/azure/azure-resource-manager/templates/deployment-history
• https://learn.microsoft.com/azure/governance/policy/overview

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.
Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.