Earlier this year, Microsoft announced Azure SQL Database Serverless. This is a new compute model for Azure’s SQL Server PaaS offering. Serverless is ideally suited for infrequently accessed, non-mission critical single databases. In this post, we’ll visit relevant use cases.
One of the main benefits of Azure SQL Database Serverless is something that would make your average SQL DBA gasp: the ability to pause the instance at a time of no activity. Every SQL DBA knows the auto-close feature is something you normally ensure is turned off across your environment. Serverless is not meant for production mission-critical systems. Its use case is really infrequently accessed non-critical databases. The ability to pause the instance leads to cost savings as you’re only paying for the cores dedicated when the instance is running, and only storage costs when the instance is paused. The instance will only pause if its connection count is 0 and the CPU usage is 0 for a specified time.
Another benefit of Serverless is the ability to automatically scale up and down based on workload and connectivity. While this is beneficial for just about any compute model, databases are typically monolithic in design. This poses issues when scaling. Databases are usually monolithic and require scaling up or down instead of out or in. This means we are adding or removing resources from our single instance vs adding or removing additional instances. Downtime is usually minimal, but it does occur. Additionally, because databases rely heavily on caches for performance, scaling down is often a huge performance hit, regardless of the reduced workload. For these reasons, provisioning mission critical systems on dedicated resources is recommended.
The main use case for Serverless is infrequently accessed databases. There are many instances where this may be the case. Last year, I migrated a client’s read-only database to Azure as an Azure SQL Database. The client had retired this application in favor of a new application, but developed functionality within the new app to occasionally query this data. This would be a perfect use case for Serverless. In general, compute costs for Serverless are higher than provisioned, so taking advantage of its benefits is critical to effectively managing costs. Let’s look at some things to consider next.
Configuration and considerations
Serverless requires the configuration of a few parameters. Serverless supports automatic scaling, so minimum and maximum vCore settings need to be configured. The minimum vCore is 0.5, and the maximum is 16. It should be noted that, as you set the maximum vCore higher, starting at 6 vCores, the minimum vCore also increases.
Additionally, the autopause settings must be configured. After this amount of time with zero activity, the instance will pause. When the instance is paused, the first connection to the database will return a 40613-error code stating the database is unavailable. If an application connects to this database it will require retry logic to smoothly connect to a database that is paused. As this is a compute tier, the process of migrating to Azure SQL is the same.
Due to the increased configuration in Serverless, billing is a little more complicated than for provisioned. Billing is always: compute + storage. When compute usage is between the min and max vCores, it is billed at the actual usage. When it’s below the min vCore, it is billed at the minimum vCore. If the database is paused, only storage is billed.
It’s worth noting that the vCore cost for Serverless is almost twice that of provisioned. It stands to reason that if this database is only utilized 50% of the time, it likely makes sense to look at Serverless.
Azure SQL Serverless has the potential to save a lot of money with infrequently accessed databases. If your organization uses SQL databases you’re interested in migrating to Azure, Anexinet’s ample experience with migrations can assist in calculating the best performance tier for Azure databases. Please reach out to us, as we would love to discuss your Azure or SQL journey in more detail.
SQL Server Architect
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.