This article is the third in a series that provide a high level overview of some of the major differences you can expect between the AWS RDS SQL Server service and the Azure SQL Database service. Both offerings are considered Platform as a Service (PaaS) implementations, which by nature offer certain limitations that we will cover. This article does not review the Infrastructure as a Service (IaaS) implementation of SQL Server. You can
view the first article here, in which I covered differences in architecture, availability, connectivity, licensing and major SQL features. The second article (
here) focuses on backup and security. This article focuses on scalability specifically.
Scalability
Let’s define scalability as a system’s ability to handle new consumers without a noticeable impact on existing consumers. In other words, a system can scale when there is an increase in workload without degradation of service. Two methods are available for scaling any given system: vertically and horizontally. Other techniques exist, such as caching, but we won’t address external solutions here; just those provided by the service itself.
AWS RDS SQL Server
Because the AWS RDS SQL Server service is based on a deployment of regular SQL Server installations, the scalability options are limited to what you can do on your own: scaling up. You can easily scale up existing SQL Server installations by adding memory, IOPS, and CPU cores to an existing server. This means that the AWS RDS SQL Server service will scale up to the limits of what the hardware can provide. If you need additional capacity, you simply need to upgrade to the next level of hardware. This isn’t particularly hard in AWS RDS; Amazon is trying to make this process as smooth as possible, but it may require downtime of a few minutes. In order to make this a bit easier to absorb the AWS RDS service provides specific maintenance windows during which these changes can be done, minimizing the impact to consumers.
There are various hardware options for the AWS RDS SQL Server service. Your options vary based on the edition of SQL Server you choose. Interestingly enough, scaling is not always about going “up”; sometimes you need the ability to go “down”; why pay more than you need to? On this front, the AWS RDS service has limited options for SQL Server. If you choose SQL Server Standard Edition, your smallest instance option is an m4 or m5 Large (the m5 option provides 1 core, 2 vCPUs, 8GB RAM, up to 3,500 Mbps ESB), which is almost $1 per hour in the US (pricing is non-reserved, single instance). You can significantly reduce your costs by choosing the express edition of SQL Server, which would turn out to be about $15 per month (more or less) for the smallest size available (T2 Micro).
Of course your scale up options are also limited, so this approach works until you run out of options on the hardware offering, at which point you are forced to look at the application architecture or look at other scalability options outside of SQL Server. Still, the upper boundary is an M5 24xlarge, a true beast of nature, providing 48 cores (96 vCPUs), 384 GB of RAM and 14K Mpbs for ESB storage.
Last but not least, since AWS RDS SQL Server gives you a full blown SQL Server installation, you can easily load multiple databases on the same server. This allows you to consolidate databases on the same server; while this isn’t part of the service itself, the database engine allows you to do so.
As simple as AWS RDS SQL Server scalability options are, they are nonetheless well understood and easy to establish from a capacity planning standpoint. This makes it particularly easy to fork and lift existing workloads and predict what size you will need in AWS.
Azure SQL Database
For the Azure offering, things are a bit different. You can also scale up, as is the case for AWS RDS; adding more resources to your database instance certainly helps resolve certain types of scalability requirements. There are two sizing unit for a SQL Database: DTU and vCore. The DTU (Database Transaction Unit) model applies to the Single Instance model, while the vCore model (more closely aligned to the AWS RDS offering) is only available for Managed Instances. The DTU model provides general performance characteristics that can vary somewhat depending on the workload, and can make it difficult to know exactly what you are getting; however this model works well for many large databases and offers some very low-priced options as well for the low-end of the scalability spectrum. For a complete overview of the DTU model please see
Microsoft’s Azure DTU-Based Purchasing model page. At the time of this writing the Azure SQL Database service offers up to 80 vCores with 396GB RAM.
Where the Azure SQL Database offering shines is in the granularity of its scalability options. The DTU models allows you to be very selective on the overall performance needs of your database (hence allowing to just pay for what you need). You can fine-tune your performance requirements at will with minimum impact to your service.
Elastic Pool
In addition, the Azure SQL Database service allows you to create an elastic pool (this is an offering of the Single Instance model; not available for Managed Instances). An elastic pool allows you to co-locate databases under a single Azure SQL Database server, allowing to share the overall performance characteristics of the instance. This offering is particularly useful when you are hosting multiple databases with scattered performance characteristics, so that on average all the databases consume roughly a known amount of resources (DTU or vCore).
Serverless
In terms of the ability to scale down, the Azure SQL Database service recently introduced the concept of a serverless database. This option is only available for the vCore offering. With a serverless database the service itself is paused after a configurable period of inactivity, which essentially means that you are not paying for the service while it isn’t being used (except for storage). This option is excellent for development and testing environments that are not used 24x7.
Scale-Out
The SQL Database service provides the main capabilities around scale out:
Read Scale-Out and
Sharding. The Read Scale-Out feature allows you to read from a secondary replica of the database, hence freeing the primary replica from heavy reads. This option is only available with the service tiers that allow secondary replicas (such as the Premium, Business Critical and Hyperscale tiers). The sharding feature is a set of tools allowing you to distribute (split/merge) data across multiple databases, and a client library that helps you query across the shard.
In summary, the scalability options for AWS RDS and Azure SQL Database are very different in nature. Both offer scale up and down options, with AWS RDS being somewhat limited. However there are no scale-out options for AWS RDS at this time.
|
Scalability
|
AWS RDS SQL Server
|
Azure SQL Database
|
|
Scale Up
|
Machine Size
|
vCore, DTU
|
|
Scale Down
|
Machine Size
|
vCore, DTU, serverless
|
|
Scale Out
|
n/a
|
Read Scale-Out, Sharding
|
|
Consolidation
|
Machine
|
Elastic Pool
|