# Azure Database for MySQL (Single Server)

> Azure Database for MySQL Single Server bills for provisioned compute 24/7 and has no stop capability, since Microsoft retired the SKU in favor of Flexible Server. ZopNight discovers lingering instances via Resource Graph, quantifies 60 days of utilization, and flags each one for migration to Flexible Server, which can be scheduled.

Source: https://zop.dev/integrations/azure/mysql
Updated: 2026-08-19

---

Azure Database for MySQL Single Server is the legacy managed MySQL offering, billed for provisioned compute around the clock. Microsoft has retired this SKU in favor of Flexible Server, making lingering instances both a cost and a migration flag.

## A retired SKU that still bills around the clock

Single Server charges for its provisioned compute tier every hour of every day, with a separate meter for provisioned storage and backup retention beyond the included amount. There is no stop operation on this generation of the service, because the platform simply never exposed one, so the only ways to reduce the compute line are to shrink the tier or to leave the SKU behind entirely. That is exactly why these servers matter: each one represents spend that cannot be paused no matter how idle the workload is.

## How ZopNight treats Single Server MySQL

Discovered via Azure Resource Graph. Azure Monitor metrics (60-day lookback) and Cost Management billing quantify usage and spend, and recommendations flag migration to Flexible Server and rightsizing. Because the type is not schedulable, ZopNight surfaces it primarily so teams can plan migration to Flexible Server, which is schedulable. The recommendation carries the utilization evidence a migration case needs.

## Why migration is the real saving here

Rightsizing a Single Server trims the meter; migrating replaces it with one that can be switched off. A non-production MySQL server needed only during working hours spends most of the week idle, and on Flexible Server that idle time stops billing for compute. On Single Server it never does. Teams that treat these instances as ordinary databases rather than migration debt keep paying the full 168-hour week indefinitely, and they also stay on a product line Microsoft has already retired.

## Common leaks on legacy MySQL servers

Watch for three things: forgotten dev and test servers created years ago and never revisited; tiers sized for a launch that traffic never justified, visible immediately in the 60-day utilization data; and servers whose only remaining consumer is a report or cron job that could run against a far smaller, or stoppable, target.

## Locating Single Server instances in the portal

Azure portal → Azure Database for MySQL servers lists both generations side by side; the Deployment type column distinguishes Single Server rows from Flexible Server ones, which makes it the quickest inventory of what still needs migrating.