SQL Server is Microsoft's flagship database. It was released almost 30 years ago and it's still going strong today. So, of course, Azure has its own options for running SQL Server databases. The costs for SQL Server databases range from about €4 (basic) to over €18,093 (business-critical 80 vCores and 4 TB), so there should be something between those price ranges that fits your needs.
You have two options when it comes to hosting a SQL Server database in Azure. You either go for Azure SQL Server, which gives you a nice database instance without much hassle, or you host a VM and install SQL Server on that. Azure SQL is a Platform as a Service (PaaS) solution, while a VM is an Infrastructure as a Service (IaaS) solution. Since the IaaS solution that's installing your database on a VM is basically the same as hosting your own on-premises version of SQL Server, except on a machine running in the cloud, we're not going to talk about that in this chapter. This chapter will focus on PaaS solutions.
If you're looking for IaaS solutions, Azure has plenty of VM images that come with preinstalled (SQL) databases, such as SQL Server 2008 all the way up to the newest release, in different versions such as Standard and Enterprise, and even with different service packs installed. You're not limited to SQL Server either; you can pick images with Oracle, Postgres, MySQL, MongoDB, Neo4j, and plenty of others. The IaaS solution is ideal for a rehost or lift-and-shift migration, as discussed in Chapter 1, Strategies for App Modernization Using Azure.
When you're looking for a SQL PaaS solution, your options are much more limited. There's Azure Database for MySQL, PostgreSQL, and MariaDB in preview, and then there's Azure SQL, which I'm going to discuss here. I'm not going to discuss all four SQL databases, but if you're interested in MySQL, PostgreSQL, or MariaDB, you can check out the links in the Further reading section at the end of this chapter. Azure SQL is not the same as the on-premises version of SQL Server. They share the same engine, but Azure SQL doesn't give you the same type of control that SQL Server gives you. This is inherent to PaaS because you're not controlling the infrastructure, so you don't have access to the underlying OS. That being said, for a lot of databases, the transition will be rather painless. All your SQL code is still supported, after all. As such, migrating to PaaS solutions can usually be done while refactoring, rearchitecting, or rebuilding. See the Further reading section at the end of this chapter for a side-by-side feature comparison.
You can also use the Data Migration Assistant (DMA – see the Further reading section), which helps you by looking for compatibility issues, such as unsupported or partially supported features, in your current database and Azure SQL (or any other SQL Server database).
Microsoft recommends hosting SQL Server in a VM for quick migrations to Azure as it closely resembles what you have on-premises. However, there is a third option: the Azure SQL Database Managed Instance. It provides nearly 100% compatibility with the latest Enterprise edition of your on-premises SQL Server. In this chapter, we're not going to use this, though, as it's not (yet) available in all locations or on all subscription types, it's quite expensive (starting at over €1,000), and it can take up to 6 hours to create.
![]()
Creating an Azure SQL Database is surprisingly easy. Follow these steps to do so:
- Either find your SQL databases or go to Create a resource and find SQL Database.
- In the blade that opens, select a subscription.
- Select or create a resource group.
- Give the database a name. This is your database, so it doesn't have to be unique across Azure.
- The next part is a little tricky; we need to create an actual server:
- Provide a name for your server; it has to be unique across all of Azure.
- Enter the name of your server's admin.
- Enter a password that meets the requirements (Azure will show you what those requirements are if you don't meet them).
- Confirm the password.
- Select a location.
- Keep Allow Azure services to access server checked. For non-development purposes, it's recommended to uncheck this option as it gives any Azure resource access to your server, even those not in your current subscription.
- Now, we can go back to the SQL database settings. We don't want an elastic pool right now.
- The pricing tier is interesting; you can go for the Basic tier here, which is already more than we need. I've picked standard with some extra DTUs:
- Leave the collation.
- When you have filled everything out, you can click Create and the SQL database will be created; this may take a few minutes:
Let's look at the settings that may not be familiar to you. First, there's a server you have to create. Even though Azure SQL is a PaaS solution, you get some control over your server, mostly in terms of backups and security, which will be discussed in Chapter 12, Securing Your Azure Services, and Chapter 14, Designing for High Availability and Disaster Recovery.
With a server, you have a set number of resources that you pay for during the month. When you have multiple databases with varying and unpredictable periods of usage, a server may be sitting idle a lot of the time and peaking a few times a day or week. To overcome this problem, Azure introduced SQL elastic pools, which autoscale individual databases within set parameters as necessary. So, databases under light loads consume fewer resources while databases under heavy loads consume more resources. By placing these databases in a pool, you can save costs since they can share resources.
![]()
The cost of your SQL database depends on two things: the size of your data and the number of DTUs you have. There are three DTU-based tiers: Basic, Standard, and Premium. The Basic tier gives you five DTUs and a maximum of 2 GB of data. A D...
