3.1.1.2. Design for Azure Database for MySQL, PostgreSQL, and MariaDB
3.1.1.2. Design for Azure Database for MySQL, PostgreSQL, and MariaDB
💡 First Principle: Providing managed open-source databases as a service enables organizations to leverage familiar technologies and ecosystems while offloading the operational burden of infrastructure management, patching, and backups.
Scenario: You are designing the data layer for a new web application built on WordPress (which uses MySQL). Your development team is highly familiar with MySQL, and you want to leverage managed Azure services while minimizing the need for refactoring the application.
Azure Database for MySQL, PostgreSQL, and MariaDB are fully managed relational database services for open-source database engines.
Key Design Considerations:
- Scalability:
- Flexible Server and Single Server deployment models support vertical scaling (changing VM size) and horizontal scaling (with read replicas).
- Flexible Server enables zone-redundant high availability and custom maintenance windows.
- High Availability:
- Automatic backups, point-in-time restore, and geo-redundant backup options ensure data protection and disaster recovery.
- Security:
- VNet integration (Virtual Network) and Private Link, SSL/TLS encryption for data in transit, and Microsoft Entra authentication secure data and access.
- Performance:
- Query performance insights, slow query logs, and monitoring tools support optimization.
- Open-source engines allow custom extensions and configurations.
Design decisions in practice:
| Decision | Guidance |
|---|---|
| Which engine | Follow the application. These are managed builds of the open-source engines, so the choice is made by what the code already speaks — migrating between engines means rewriting queries, not changing a setting |
| Deployment option | Flexible Server is the current model and the default answer. It provides zone redundancy, a configurable maintenance window, and stop/start for non-production |
| High availability | Zone-redundant HA places the standby in a different Availability Zone with automatic failover. Same-zone HA is cheaper but survives only a node failure, not a datacenter one |
| Non-production cost | Stop/start is the biggest lever — a dev server stopped overnight and at weekends costs a fraction of one left running |
Reaching them privately follows the same pattern as every other Azure PaaS data service: private access injects the server into a delegated subnet of your VNet, while public access keeps a public endpoint governed by firewall rules. Only the former removes the public surface, and the choice is made at creation time — it cannot be switched later without redeploying.
⚠️ Exam Trap: Single Server has reached retirement. A scenario that mentions it is describing a migration that is already overdue, not a deployment option still on the table.
⚠️ Common Pitfall: Choosing the older "Single Server" deployment model for new projects. "Flexible Server" is the recommended option as it provides better performance, more control over configuration, zone-redundant high availability, and custom maintenance windows.
Key Trade-Offs:
- Open-Source Compatibility vs. Azure-Native Features: These services provide high compatibility with their open-source counterparts, making migrations easier. However, they may not have all the advanced, deeply integrated features of a proprietary service like Azure SQL Database (e.g., Hyperscale).
Reflection Question: How does choosing Azure Database for MySQL Flexible Server (or PostgreSQL/MariaDB) fundamentally enable organizations to leverage managed open-source relational databases, balancing open-source compatibility and familiar tooling with cloud benefits like scalability and high availability, making it suitable for cloud-native and migration scenarios?
