As applications grow, you need to be able to accommodate the need for more storage and more processing power to cope with demand. Sometimes, this growth is organic and happens naturally over time as your service becomes more popular.

For some applications, the need to rapidly scale out is known ahead of time—for example, with reporting solutions where you know you will be ingesting large amounts of data.

Within Azure, there are many options for achieving growth. However, the correct choice will, as always, depend on your precise requirements and solution architecture.

Both Cosmos DB and Azure SQL Database design for scale from the outset. As we saw in the previous section, the available tier is built around Azure storage with separate compute nodes. Upgrade to the Hyperscale tier, and your databases can grow up to 100 TB. However, in order to manage additional storage, you must also increase the compute capabilities.

The default options for scaling out compute entail manually increasing the number of vCores or DTUs to meet your needs. For some scenarios, this hands-on process may be adequate for your needs.

However, the scaling process for single databases or a managed instance is not immediate. Behind the scenes, moving from one vCore or DTU level to another, or when moving between tiers, involves copying your database to a new instance of a new size. Once the copy is complete, the compute node then flips over to the new service.

If you have multiple databases and you need databases to be able to scale automatically based on demand, you can instead opt for elastic pools.

With an elastic pool, you can define a number of elastic DTUs (eDTUs) or vCores, and then within that pool, you can set the maximum number of DTUs or vCores per database. Once set up, the resources within the pool will be automatically assigned to the database that requires the resources at any one time, as we can see in the following diagram:

Figure 12.5 – Azure SQL elastic pools

The preceding scenarios are only applicable to Azure SQL options; with Azure Cosmos DB, we have already seen that scalability is built in. Cosmos DB automatically replicates, and scales as required. This means Cosmos DB can guarantee low latency, high availability, and high performance anywhere in the world.

Another alternative to elastic pools is the serverless option, which is available for an Azure SQL single database or Cosmos DB. As we saw in the previous section, the serverless tier for Azure SQL Database allows you to define an upper vCore count and have Azure automatically scale on demand. Similarly, the Azure Cosmos DB serverless options also automatically scale on demand but lack the ability to control an upper limit.

Manual scaling or autoscaling is excellent for building solutions that can leverage the power of near-unlimited resources to enable your applications to grow over time (even if it’s a short period of time) without needing to invest upfront in hardware.

Some solutions start big, and although Azure provides massive amounts of resources, there are times when you need to employ different architecture patterns to achieve performance at scale. Two such options are read replicas and database sharding.