Azure Database for MySQL

About Azure Database for MySQL

Azure Database for MySQL is Microsoft's fully managed MySQL service for teams that want to run MySQL applications on Azure without maintaining the underlying operating system, database host, patching process, or backup platform themselves. The current Flexible Server architecture supports MySQL Community Edition versions 5.7, 8.0, and 8.4, and gives buyers a choice of Burstable, General Purpose, and Memory Optimized compute tiers. It is a practical fit for web applications, SaaS products, line-of-business systems, and migration projects that need familiar MySQL compatibility with Azure-managed availability, security, monitoring, and scaling.

What workloads fit Azure Database for MySQL?

Azure Database for MySQL is best suited to applications that already use MySQL or need the MySQL ecosystem without requiring direct control of the database host. Microsoft positions the service for production-ready relational workloads, while the Burstable tier is aimed more at development, proof-of-concept, and low-concurrency scenarios. General Purpose is intended for balanced business workloads, and Memory Optimized is designed for database workloads that need more memory and higher concurrency.

The managed model removes routine infrastructure work such as operating-system maintenance, database-engine patching, automated backup scheduling, and much of the availability plumbing. That can shorten deployment time for teams that would otherwise run MySQL on Azure Virtual Machines. The tradeoff is that some host-level control and unsupported extensions or operating-system customizations are not available in the managed service.

How do compute and storage choices affect cost and performance?

Flexible Server separates compute, storage, IOPS, and backup consumption so the bill depends on how the database is configured and used. Burstable can reduce cost for intermittent workloads, but Microsoft warns that CPU-credit exhaustion can reduce performance, which makes the tier a poor choice for sustained production demand. General Purpose and Memory Optimized provide more predictable capacity for production systems.

Storage can be scaled online and Azure Database for MySQL supports additional IOPS above the amount included with provisioned storage. Microsoft is also previewing Premium SSD v2 for selected workloads, with independent scaling of storage capacity, IOPS, and throughput. Buyers should size around real database behavior rather than selecting a large server only to compensate for inefficient queries or storage bottlenecks.

How does high availability and backup work?

Microsoft supports both local-redundant and zone-redundant high availability in eligible regions and configurations. High availability adds a standby server and automatic failover behavior so a production application does not depend on one database node. Zone-redundant high availability is the stronger choice when the workload must tolerate a full availability-zone failure, but availability depends on regional capacity and supported configurations.

Automated backups support point-in-time restore with configurable retention from 1 to 35 days. Microsoft encrypts backups and also supports geo-redundant backup in selected regions. Backup retention, geo-redundancy, and data growth can affect cost, so buyers should treat backup policy as both a recovery decision and a cost decision rather than leaving the default unchanged.

What networking and security options are available?

Flexible Server can use public access with firewall rules or private access through virtual network integration. Microsoft recommends private access for stronger network isolation when the application can run within Azure networking or connect through VPN or ExpressRoute. The connectivity model should be chosen carefully because the deployment method can limit later changes.

The service supports encrypted connections, Azure monitoring, Microsoft Entra authentication in supported configurations, and Azure-native controls around identity and networking. Customers still remain responsible for database users, application credentials, schema design, query security, least-privilege access, and the data placed in the service.

How can teams scale read-heavy workloads?

Azure Database for MySQL supports read replicas for workloads where read traffic can be separated from the primary server. Microsoft currently documents support for up to 10 replicas, using native MySQL binary-log replication. This can help reporting, read-heavy APIs, or geographically distributed application patterns, but replication is asynchronous, so applications must tolerate lag between the primary and replica.

Read replicas are billed separately for their provisioned compute and storage. A replica should therefore solve a measured read-scaling problem rather than be added automatically. Applications may also need connection-routing logic or a proxy such as ProxySQL if they want to distribute read traffic without major application changes.

What should buyers know about pricing?

Pricing was checked on August 27, 2026. Microsoft bills Azure Database for MySQL primarily through provisioned compute, storage, backup storage beyond included allowances, additional or paid IOPS, read replicas, networking, and optional capabilities. Current Microsoft pricing also offers one-year savings options on selected compute families and can charge separately for features such as Accelerated Logs in eligible General Purpose configurations.

There is no single monthly product price that applies to every deployment. Region, compute family, tier, high availability, storage, IOPS, backup design, and replica count all change the bill. Teams should model steady-state and peak usage separately, then compare pay-as-you-go with commitment options only after they have enough usage history to justify the commitment.

What current lifecycle details matter?

Microsoft currently supports MySQL Community Edition versions 5.7, 8.0, and 8.4 in Flexible Server, subject to Microsoft's version-support policy. In June 2026, Azure Database Migration Service added support for migrating workloads to MySQL 8.4. In July 2026, Microsoft announced a private preview of Premium SSD v2 storage for selected MySQL Flexible Server workloads.

Buyers should check version support and preview status before planning a long-lived deployment. Preview features can change and should not be treated as production guarantees unless Microsoft explicitly documents production support for the workload and region.

When should you choose another Azure database option?

Choose Azure SQL Database when the application is designed around Microsoft SQL Server features or Transact-SQL and would benefit from Microsoft's SQL-native managed platform. Choose Azure Cosmos DB when the workload needs a globally distributed NoSQL model, flexible consistency, or massive horizontal scale rather than relational MySQL semantics. Choose PostgreSQL Flexible Server when application compatibility, extensions, or team expertise favors PostgreSQL.

Running MySQL on Azure Virtual Machines can make sense when the application requires operating-system access, unusual plugins, deep server customization, or a version and configuration that the managed service does not support. That flexibility comes with more responsibility for patching, backups, high availability, security, and operational recovery.

Who should choose something else?

Teams should choose something else if they need complete host control, unsupported MySQL plugins, custom operating-system software, or database configurations that Flexible Server does not expose. Very small applications may also be better served by a simpler hosted platform if a dedicated managed database adds unnecessary operational and cost complexity.

Organizations already standardized on another database engine should not migrate only to use an Azure-branded service. The strongest fit is an application that genuinely needs MySQL compatibility and benefits from Azure-managed backups, availability, networking, monitoring, and scaling.