When you’re start implementing Dynamics 365 Business Central on-premise (because you’re not ready for the SaaS now), one of the good decision you can take today is to move your database to the cloud. I’ve written in the past different posts on when and why using Azure SQL Database or SQL Server installed on an Azure VM with Dynamics 365 Business Central (same is for NAV if you want). You can find some links here and here.
Normally, my personal experience is resumable as follows:
But what about if you need the best performances? Costs are not always the main aspects to consider in this case, expecially if you’re starting a big project (many concurrent users). For very big projects, using SQL Server on an Azure VM without apsects like scaling, monitoring and so on could be a bottleneck.
Today I want to signal a very interesting new option that you can start considering: Azure SQL Database Hyperscale.
Azure SQL Database Hyperscale is a SQL-based and highly scalable cloud service tier for single databases. It has a cloud-born architecture which decouples compute, log and storage and it provides you with up to 100 TB of storage, with low latency and high throughput.
Main features of Azure SQL Database Hyperscale are the following:
The wonderful thing is that you can move your Azure SQL Database to the Hyperscale service tier when you want and without requiring any change to your applications using the database (connection strings are always the same).
I’ve done in the past days some tests on this new service tier and results are very interesting.
To check the gains on performances, I’ve installed a Dynamics 365 Business Central database instance on an Azure SQL Database with the Standard tier (General Purpose, Gen5, 2vCores), I’ve performed some tasks inside this instance and then I’ve moved the database to the Hyperscale service tier.
This is my Dynamics 365 Business Central database running on the Standard service tier:
and this is the monitoring of resources when performing some business tasks (a set of pre-defined tasks that runs for 15 minutes):
After these tests, I’ve switched the database service tier to Hyperscale tier (I suggest to select Gen5 as compute generation because in this way you run on the latest hardware generation). Here I’ve also set the vCore number to 2 (estimated price doubles, you are not forced to do that now and you can stay with defauls values and switch them later if you need more power):
When you click Apply, your database starts moving to the new service tier (wait few minutes):
and when ready you receive a confirmation message:
Now our Dynamics 365 Business Central database runs on the Azure SQL Database Hyperscale tier (you can check the new applyed service tier by going to the database properties):
Let’s repeat the same tests now (same set of tasks for the same time slot). The resource monitor when the database is switched to hyperscale is in the red box in the below image:
NOTE: results displayed here are on a database with a single user that performs intensive tasks. Gain on performances will be more when the number of users increases.
I’ve simulated a load test also by using a Powershell script that performs intensive queries on the database for a long period of time and what I can say is that Hyperscale tier is extremely interesting if you want you have great performances.
Remember that if you switch to the Hyperscale service tier you cannot go back to the Standard tier.
P.S. you pay per resource’s consumption, costs could be not too much compared to performances that you can have.