[SQL Database][vCore] Support for Storage Auto Growth

[chirangaalwis]

While evaluating the service tier options under Storage, it was noticed that Azure SQL Database service tiers - General Purpose and Business Critical do not mention about the availability of support for storage auto growth (at least within a range specific to the relevant service tier). In contrast, the Hyperscale service tier provides flexible auto growth of storage.

During database creation, no option seems to be available to enable storage auto growth (e.g as in the case of Azure MySQL service).

• Can you please confirm whether the General Purpose and Business Critical service tiers do not provide this feature?
• If yes, do we need to manually handle storage increments (within the range specific to the service tier)?
• If this requires manual intervention, does the Azure SQL team have any recommendations for automating this process to allow instant self remediation?

---

Document details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b154f4ad-6372-ac17-3084-1ff016073568
• Version Independent ID: 8c4a54f3-8db5-7839-3008-724beecc3888
• Content: vCore purchasing model overview - Azure SQL Database & Azure SQL Managed Instance
• Content Source: articles/azure-sql/database/service-tiers-vcore.md
• Service: sql-db-mi
• Sub-service: features
• GitHub Login: @stevestein
• Microsoft Alias: sstein

[Oury-MSFT]

@chirangaalwis Thank you for your feedback. We are looking into this and will get back shortly. Thanks

[Oury-MSFT]

@chirangaalwis Auto scaling is not available for General Purpose or Business Critical. SQL DB hyperspace supports it. @stevestein Is there a way to automate scaling for Azure SQL General Purpose and Business Critical?

[dimitri-furman]

@chirangaalwis - Correct, all Azure SQL service tiers except Hyperscale do not provide storage auto-growth. This lets customers maintain the ability to scale down to a lower service objective that does not support higher storage sizes. Otherwise, a database could grow its storage consumption high enough to prevent scaling down.

Explicitly managing maximum data size also lets customers better manage their storage and backup costs. In vCore databases, backup storage up to the maximum data size is free, so depending on workload patterns it is sometimes possible to reduce the overall bill by setting a higher maximum data size than what is needed for current data.

These two considerations do not apply to Hyperscale, where maximum data storage is the same regardless of the service objective, and is auto-scaling as it is consumed, up to 100 TB.

There are several published approaches to auto-scaling Azure SQL DB databases. You will need to evaluate them in your specific context, there is not a single solution for all scenarios. That said, most of our customers do not implement storage auto-scaling and prefer to handle this on an ad-hoc basis.

[MashaMSFT]

Hi @chirangaalwis , thanks for contacting Microsoft! Since Dimitri addressed your question, I'll go ahead and close out this Git Issue. However, please feel free to comment should you need further assistance.

Thanks again for reaching out, and I hope you have a wonderful rest of your day! Masha from the SQL Docs team

reassign:dimitri-furman

please-close