Skip to main content

Microsoft Build: Azure Adds Azure Database for MySQL, Azure Database for PostgreSQL

Posted on May 11, 2017 by DougVanderweideDougVanderweide

A significant announcement at Microsoft Build 2017 was support for MySQL and PostgreSQL as a service. Both offerings are now in preview.*
Azure has technically supported MySQL as a service for several years, through its partner, ClearDB. I’d say it’s safe to report that few Azure users were impressed with the offering, which was expensive, especially given its limitations.
Last summer, Azure also announced the ability to create MySQL databases within an App Service app, but these were limited to operating within a specific app instance and therefore couldn’t scale, couldn’t be reached from outside the app and had their performance limited by the capabilities of the App Service instance.
So the offering of MySQL as a service from Microsoft itself, as well as PostgreSQL, is a welcome development (pardon the pun), mostly because it promises to be truly scalable, which the ClearDB offering was not, and will overcome the limitations of running databases in App Service instances.

Screenshot from the Azure portal, showing the MySQL and PostgreSQL as a service offerings.

Screenshot from the Azure portal, showing the MySQL and PostgreSQL as a service offerings.

Provisioning these new services is simple. From the portal, click the new button, then select Databases. You’ll see both offerings about halfway down the blade that comes up; select whichever you prefer.

Service Sizing And Pricing

MySQL and PostgreSQL are provisioned, and priced, based on the computing power and storage capacity of the database.  Compute units are similar to the data transaction units, or DTUs, and are used to calculate the service level for an Azure SQL Database: The more of them you have, the more work your database can perform. As with DTUs, compute units are a linear measure: A database that has 100 compute units can do twice the work of a database with 50 compute units.
At the moment, there is only a basic service tier, but the portal indicated standard and premium tiers will become available, much as it is with Azure SQL Database. At the moment, you can only allocate 50 or 100 compute units, but your storage can range from 50 GB to 1 TB, the size limit of page files in Azure Storage.
MySQL 5.6 and 5.7, or PostgreSQL version 9.6 and 9.5, are supported. The pricing for each service is the same; in South Central US, that’s $15 per month for 50 compute units and 50 GB of storage, up to $101.60 per month for 100 compute units and a terabyte of storage.

Security and Monitoring

Both MySQL and PostgreSQL databases are protected by firewalls, which initially require SSL connections and block all external connection requests. You can add your IP address, or a range of IP addresses, to the firewall rules to allow access.
However, a major drawback of both is that as of this writing, you can’t restrict connections to only Azure-based services, the way you can with Azure SQL Database. Says Microsoft:
Note Azure Database for MySQL (Preview) doesn't yet enable connections only from Azure services. As IP addresses in Azure are dynamically assigned, it is better to enable all IP addresses for now. As the service is in preview, better methods for securing your database will be enabled soon.
Yeah, that’s exactly as terrible as it sounds. You are probably best off using MySQL and PostgreSQL as a service only with those Azure services that can be assigned a static IP address, such as virtual machines and Web Apps.
You can add alert rules based on CPU/compute unit use; storage; memory use; and connection rates, both current and failed. Or you can add in activity alerts common to many Azure services, such as failed login attempts, service failure and the like.
Metrics are available for the parameters that allow for alerts, as is support for logging slow queries and the like.
*: In Azure, “public preview” means that you can use a service, but there’s no guarantee it is going to work as expected, there are probably some important features that are missing, not available yet or that don’t function properly, and there’s no SLA. I have found that most public preview technologies are reliable, but you should use caution deploying production workloads to them. As in, don’t.


Leave a Reply

Your email address will not be published. Required fields are marked *