Choosing between SQL Azure and Windows Azure Storage
February 16, 2011 Leave a Comment
I was having a chat with an Azure architect at Microsoft last week, and he pointed out that SQL Azure storage costs 66x (yes, sixty-six times) Table Storage.
Not quite believing I went back to check pricing. And sure enough it’s true. In fact it is probably an even higher ratio as you have to buy SQL Azure in chunks of 1,5,10,20 GB etc.
If you have 15Gb of data in SQL Azure you need a 20Gb database @ ~$200/month.
15 Gb of data in Table Storage = 15 * $0.15 = $2.25 / month.
That would make SQL Azure around 89x as expensive as Table Storage.
Wow.
That’s not quite the full story though. In Table Storage the idea is that you would often not normalise your data. Data is likely to be stored multiple times in the store. And additionally there are transactional costs associated with Table Storage ($0.01 per 10,000) transactions. These both make estimating cost more tricky.
As a guestimate starting point, let’s say I need to store each data item 3 times in Table Storage, meaning that 15Gb of normalised data gives me a requirement of 45Gb Table Storage. If my system has 1000 users each performing 10,000 transactions / month, then my total Table Storage costs would be:
(45 * $0.15) + (1000 * $0.01) = $16.75 / month
That’s about a 12x ratio (and is based on a lot of assumption too).
There’s probably a need for a simple spreadsheet to help look at the trade-offs here, but as a rule of thumb the pricing model from Microsoft is giving us some strong guidance: Windows Azure architects should look to put data in Windows Azure Storage first and SQL Azure conservatively.
The two scenarios I see when I would prefer SQL Azure over Table Storage are:
- When I need SQL Transactions – ie. the ability to group together a bunch of database actions and commit them as a single atomic unit. There’s no concept of this type of transaction in Table Storage.
- When I need reporting – especially enabling end-users to design their own queries and reports. In this case I don’t know how the user will want to query the data at design time and will need to rely on SQL Servers ability to query across tables to enable this.
