Usage patterns and requirements for any type of database vary greatly depending on the application that uses them. In an on-premises scenario, you would need to calculate the optimum amount of RAM, CPU cores, and disk configurations to best optimize a database or set of databases for any given solution.

In Azure, unless you opt for running SQL on a VM, many of these configuration details are abstracted away, and instead you must choose a pricing model and a service tier.

Because Cosmos DB and Azure SQL Database are different platforms, the configuration options are also different. Therefore, the options for each must be considered separately. We will start by understanding Azure SQL pricing tiers.

SQL Database tiers

Azure SQL has the most options available; you must decide between a pricing model, a service tier, and even different SQL products.

You essentially have two options when it comes to choosing a Platform-as-a-Service (PaaS) SQL product. When creating a SQL database in Azure, you must decide whether to use Azure SQL Database or Azure SQL Managed Instance.

Azure SQL Database options

Both options are fully managed versions of SQL, and by this we mean that the Azure platform takes care of availability, security patches, updates, and so on.

Azure SQL Database was introduced first and abstracted away more of the underlying infrastructure; it is much more granular in the options you can choose, especially when it comes to scaling. Because of this, some applications may not be compatible with Azure SQL Database.

Azure SQL Managed Instance offers less flexibility but offers near 100% compatibility with older, legacy databases. Some of the main differences between Azure SQL Managed Instance and Azure SQL Database are outlined here:

Another core difference between Azure SQL Database and Azure SQL Managed Instance is how they integrate at the network level.

An Azure SQL Database is built and exposed via Azure’s internal network backbone. Although through the firewalls and virtual networks blade you can restrict access via virtual networks (VNets), the SQL Server component’s Internet Protocol (IP) address is not exposed.

This can cause problems in some organizations if traffic needs to be carefully controlled or if you wish to connect on-premises systems to the Azure SQL Database via private endpoints. A PrivateLink IP can address this issue by connecting a separate internal network connection to the service. However, this service requires modifications to your corporate Domain Name System (DNS) zones, as you must override the public Uniform Resource Locator (URL) address to resolve to the internal IP address.

Azure SQL Managed Instances are built natively on a VNet within your subscription, and therefore internal connectivity is the default.

The next aspect to consider when choosing a SQL option is the pricing model. Azure SQL Database has three options: virtual core (vCore), Database Transaction Units (DTUs), and serverless.