Forum Discussion
About Azure SQL Database
So, there's two states which mean different things for the compute resources (CPU and memory):
- The SQL "serverless" service is running;
- The SQL "serverless" service is stopped (which is called "auto-paused").
The SQL service is running
- This is like when a computer is switched on, meaning you are paying for using CPU, memory and storage;
- If the SQL workload is light, the amount of memory and CPU will likely be towards the lower value limits you entered on the configuration page, which translates into a lower bill when it comes time to pay (since you only pay based on utilisation);
- If the workload is busy, the amount of memory and CPU will likely be towards the upper limits you entered on the configuration page;
- If there's no SQL workload at all for the timeframe specified as the "duration" on the configuration page, then the SQL "serverless" service is stopped (called "auto-paused").
The SQL service is stopped (auto-paused)
- This is like when you shut down a computer;
- CPU and memory are no longer being used as the SQL instance is effectively "switched off";
- This means you are saving money, as Microsoft isn't billing you for CPU or memory as the SQL instance is "switched off";
- You are still charged for storage while the instance is switched off;
- You don't have to "turn the SQL instance back on" again, as that will happen automatically once any kind of workload tries using the SQL instance again (although there will be a delay and things will run a bit slower for a short while after it starts itself back up again).
Cheers,
Lain
Thanks LainRobertson
¿What about the other two options? That is CPU Used and Memory Used. I get confused with these two, because we are talking about a scaling serverless tier that in theory doesn't have provisioned a fixed CPU or Memory
Best regards
Hey, Jonas.
"Serverless" isn't the best term as it can be a bit misleading. The servers are still there, of course, but the difference between the two relevant tiers - "serverless" and "provisioned" is how Microsoft bills you for them.
Starting with the "provisioned" tier - which is more familiar to most people since it's very much the same as a traditional server, you choose how much compute (notably, CPU and memory) and it's always there, and always "on", which in turn means you're always being charged - and at a fixed rate.
In contrast, the "serverless" tier requires that you specify minimum and maximum values for the compute, and additionally asks you for the "duration" it should wait before turning the service "off". This carries the following cost benefits:
- The fewer resources being used, the less you're being charged;
- When the service is "auto-paused" (or off, if you prefer), you're not being charged for the the compute elements (CPU and memory), meaning you're only paying for storage (since that's always in use.)
There's performance considerations as well when deciding between provisioned and serverless, but the relationship between CPU, memory and auto-pausing is a cost relationship.
Here's some succinct summaries:
- vCore purchasing model - Azure SQL Database | Microsoft Learn
- Serverless compute tier - Azure SQL Database | Microsoft Learn
Cheers,
Lain
I completely agree with you, bou my question was around the other two items in the pricing calculator of the Azure SQL Database
¿What about the other two options? That is CPU Used and Memory Used. I get confused with these two, because we are talking about a scaling serverless tier that in theory doesn't have provisioned a fixed CPU or Memory
I appreciate very much yout time and help
I think you're getting too caught up on the term "serverless".
The CPU and memory settings shown in that screenshot are the same as those found in all decent hypervisors for over a decade now, meaning they're not anything new.
Essentially, these two settings (along with duration) relate to two concepts:
- Efficient use of limited resources;
- Financial budgeting.
Behind the scenes, the "serverless" option is still ultimately running on a server - there's nothing magic about it.
SQL Server has actually had these variable settings for even longer than hypervisors have. If you've ever set up SQL Server before, you should already be familiar with specifying lower and upper memory limits and CPU affinity (not really the same thing as vCore limits but close enough for this conversation.)
The only thing within your control is setting the limits, which is generally in accordance with service usage patterns and financial budget constraints.
Cheers,
Lain
You're right, the term "serverless" got confused me. However, based on your clarification I feel much more clear.
So, we could say that CPU Used and Memory Used would be the resources this instance would use at rest, and eventually scale in the range of vCores specified
Am I right?
Best regards