Impact of Increasing database size on existing data ?

Hi Turkar, Riya-ZA,

Thanks for reaching out to Microsoft Q&A.

Changing the service tier or compute size of mainly involves the service performing the following steps:

Create a new compute instance for the database.

A new compute instance is created with the requested service tier and compute size. For some combinations of service tier and compute size changes, a replica of the database must be created in the new compute instance, which involves copying data and can strongly influence the overall latency. Regardless, the database remains online during this step, and connections continue to be directed to the database in the original compute instance.

Switch routing of connections to a new compute instance.

Existing connections to the database in the original compute instance are dropped. Any new connections are established to the database in the new compute instance. For some combinations of service tier and compute size changes, database files are detached and reattached during the switch. Regardless, the switch can result in a brief service interruption when the database is unavailable generally for less than 30 seconds and often for only a few seconds. If there are long-running transactions running when connections are dropped, the duration of this step can take longer in order to recover aborted transactions. Accelerated database recovery can reduce the impact from aborting long running transactions.

Important

No data is lost during any step in the workflow. Make sure that you have implemented some retry logic in the applications and components that are using Azure SQL Database while the service tier is changed.

Latency

The estimated latency to change the service tier, scale the compute size of a single database or elastic pool, move a database in/out of an elastic pool, or move a database between elastic pools is parameterized as follows:

Expand table

• Typically, less than 5 minutes.|- Latency proportional to database space used due to data copying.
• Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying.
• Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying.
• Typically, less than 1 minute per GB of space used.| |From Basic single database, Standard single database (S0-S1)|- Constant time latency independent of space used. - Typically, less than 5 minutes.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.| |From Basic pooled database, Standard single database (S2-S12), Standard pooled database, General Purpose single database or pooled database|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.|- For single databases, constant time latency independent of space used. - Typically, less than 5 minutes for single databases. - For elastic pools, proportional to the number of databases.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.| |From Premium single database or pooled database, Business Critical single database or pooled database|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.|- Latency proportional to database space used due to data copying. - Typically, less than 1 minute per GB of space used.| |From Hyperscale single database or pooled database|N/A|See Reverse migrate from Hyperscale for supported scenarios and limitations.|N/A|- Constant time latency independent of space used. - Typically, less than 2 minutes.|

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.