This is part 1 in my series on SQL Azure for Access Developers.
If you've ever tried to dip your toe in the SQL Azure waters, you've probably realized that you've got your metaphors all mixed up.
I mean, sure, water is blue. And in the Caribbean, much of it is even azure. But SQL Azure is a cloud service. As in blue skies. As in, I can see the cloud. I'm in a plane and I'm flying into the cloud. But once I'm inside the cloud, I can't see it. Somehow it's all around me, and yet I can't touch it. And not just because I'm inside the plane. Even if I jumped out of the plane (which I don't do anymore), I still couldn't touch the cloud.
Just thinking about it takes me back to being a kid. You look up and you see those big fluffy clouds. How amazing it would be to lay back and relax in that fluffy softness. As you get older, you learn that fog is basically clouds on the ground. And you can actually walk around inside a cloud! And it's a total letdown.
Somehow this is the perfect metaphor for SQL Azure pricing.
Dipping Your Toe In...What, Exactly?
Like childhood me staring up into the fluffy clouds, I got the itch to give SQL Azure a try.
I wasn't trying to scale the next web app to millions of users, though. I just had some line-0f-business apps I wrote in Access that I wanted to hook up to a web database and play around a bit. But, I also wanted to know what kind of ongoing costs there would be if it ever got beyond dabbling and into production use.
So, I headed over to Microsoft's web site to get some simple, straightforward pricing information.
That was my first mistake.
The Pricing Casino
If you've never walked into a casino, it's hard to describe the sensory overload you are greeted with.
There are flashing lights, clinking coins, drinks aplenty, and not a single window to alert you to the fact that it's 3 AM and you've been gambling for 5 straight–wait, what day is it again?–29 straight hours. And when you finally walk out the door, you're not really sure how much money you have any more but you're fairly certain it's less than what you walked in with.
Yep, the Microsoft Azure pricing
page web application is kind of like that:
In fact, we can't even get to the pricing page before being bombarded with calculators, how-to's, and have-you-considered's in the top navigation pane Pricing link.
Out of desperation, I picked "Azure pricing" in the top left of the dropdown. This took me to the "Pricing Overview" page. As I scrolled down, I saw the "Pricing details by product" section and realized my second mistake.
The "Pricing" button at the top of the Azure SQL page takes you to Microsoft Azure pricing, which covers dozens of cloud services. Instead, we want the "Azure SQL" pricing, which is within the page itself and not part of the top navigation bar.
Finally, Actual Azure SQL Pricing...or Not
After clicking on the actual Azure SQL Pricing link, I thought I'd finally be able to see some pricing information.
I was wrong again:
Let me save you some time here and tell you that "Azure SQL Database" is your cheapest option from the above selections. If you're like me, that's the one you're after.
Let's dig into that one a bit more.
Azure SQL Database Pricing
There are two basic purchase models: DTU and vCore.
The DTU model simplifies pricing into a predictable monthly expense. Microsoft combines processing power, memory, etc. into an arbitrary value that they call a Database Transaction Unit (DTU). You pay a fixed price. If you purchase more DTUs than you need, the excess processing power is wasted. If you don't buy enough, you'll pay for that in slower performance and more frequent timeouts.
The vCore model gives you more control over individual resources like processor power, RAM, etc. It's also more unpredictable because it varies based on your actual usage.
The DTU Model
Think of DTUs as database resource cash.
There's no straightforward way to quantify exactly what 5 DTUs gets you, other than to say that 10 DTUs gets you twice as much as whatever 5 gets you. In that way, it's just like money. Five dollars will get you a pack of hot dogs at the grocery store but only a single hot dog at a ball game. But ten dollars will get you two packs of hot dogs at the store and two hot dogs at the game.
Here's some official documentation:
DTUs are most useful for understanding the relative resources that are allocated for databases at different compute sizes and service tiers. For example:
• Doubling the DTUs by increasing the compute size of a database equates to doubling the set of resources available to that database.
• A premium service tier P11 database with 1750 DTUs provides 350 times more DTU compute power than a basic service tier database with 5 DTUs.
The vCore Model
Let's start with some official documentation:
The vCore-based purchasing model lets you independently choose compute and storage resources, match on-premises performance, and optimize price. In the vCore-based purchasing model, you pay for:
• Compute resources (the service tier + the number of vCores and the amount of memory + the generation of hardware).
• The type and amount of data and log storage.
• Backup storage (RA-GRS).
Here's the only line that really matters as far as I'm concerned:
If your database consumes more than 300 DTUs, converting to the vCore-based purchasing model might reduce your costs.
How About Some Actual Prices?!?!
OK, here's the deal. I'm going to show you (as I understand it) the lowest prices available for each option.
DTU Model Minimum Monthly Cost
These are all minimums:
- Type: Single Database
- Databases: 1
- Max Db Size: 2 GB
- Service Tier: Basic
- Performance Level: 5 DTUs
- Days per month: 31 days
The total charge would be $4.99.
That does not include backups, though. For an extra $0.19 per month, you can get backups saved for the past two weeks, the past two months, and the past two years. That takes our grand total up to $5.18.
Here's a screenshot from the Pricing Calculator:
vCore Minimum Monthly Cost
These are all minimums:
- Type: Single Database
- Backup Storage Tier: LRS
- Storage: 5 GB
- Service Tier: General Purpose
- Compute Tier: Serverless
- Hardware Type: Standard-series (Gen 5)
- Redundancy: Local
- Maximum vCores: 1
- Minimum vCores: 0.5
- Minimum Memory: 2.02 GB
- Maximum Memory: 3 GB
- CPU Used: 0.5
- Memory Used: 2.02 GB
- Duration in seconds: 3,600 (this was the Microsoft default value)
In this situation–a small database that is barely used–the total monthly cost is only $0.35.
However, what happens if you have a runaway process (say, you cross join a million-row table on itself several dozen times). Let's check out the worst-case scenario with the above minimums still in place:
- CPU Used: 1
- Memory Used: 3 GB
- Duration in seconds: 2,678,400 (i.e., every second of every day for 31 days)
In that (admittedly unlikely) situation, you could be staring at a whopping $388.19 for the month:
There is also a separate fee for backups in the vCore model. A robust backup plan will set you back less than a dollar per month, so I don't think it warrants its own screenshot and commentary.
I decided to start with the Basic tier, 5-DTU plan for about $5 per month.
For me, it's not worth saving a few dollars in exchange for the worry that one rogue process or query could cost me dozens or hundreds of extra dollars each month.
Don't Sweat It Either Way
The good news is that you don't need to worry too much about picking the wrong pricing model for your situation. It appears that moving between the two models is easy to do and requires minimal downtime.