Microsoft’s pricing for SQL Server in the cloud, SQL Azure, has been announced. It’s free for now, but around November it’ll be:
- $9.99 per month for 0-1GB
- $99.99 per month up to 10GB

SQL Azure
There’s currently a 10GB maximum size cap for SQL Azure. For larger data storage needs, you’ll need to break the database into smaller sizes.
Scaling SQL Azure Applications
If you think you’re going to need 100GB in the near term, it probably makes sense to break your application up into multiple separate databases from the get-go (10 x $9.99 = $99.99 anyway) and just make really sure none of the individual databases exceed 10GB. Ugh. I’m surprised by this strategy because Microsoft’s never been pro-sharding before, and now they’re asking database developers to make that jump. One of the things I love about SQL Server is that it scales so well: we can start with just a single database and grow it like crazy. DBAs who like that approach will not like Azure’s 10GB-per-database limits.
I’ve worked with companies who spin up a new database for every new client, copying the same database hundreds or thousands of times, and that has some serious maintenance challenges. Those companies will love SQL Azure’s scaling model, though; if each client has their own SQL Azure database, then it’s easy to pass the database hosting costs on to your clients.
Beep Beep, Back That Database Up
The bandwidth costs for SQL Azure are $.15 per GB of outbound bandwidth. Assuming that you don’t compress the data before you pull it out of the cloud, that means daily backups of a 1GB database will add another $4.50 per month, and a 10GB database will add another $45/month. Daily backups will cost about half of what your monthly service charges cost.
It’s not completely clear from the press release, but if Microsoft follows Amazon’s pricing model, bandwidth between the Microsoft cloud services will not incur a cost. That would mean it might make sense to spin up an Windows Azure computing application for $.12 per hour, use that application to compress your SQL Azure database, and then send the compressed data off to Azure storage for backup. That would eliminate the data in/out costs, and minimize the Azure storage costs ($.15/GB). Database administrators would back up their SQL Azure data to Azure Storage, keep a history of backups there, and restore them to SQL Azure faster when needed.
Of course, there’s no native backup support in SQL Azure, and it’s not clear whether Windows Azure will include tools like SQL Server Integration Services.
SQL Azure Service Level Agreements (SLAs)
The cloud isn’t 100% reliable, as the CloudComputing Incidents Database attests. The press release gives SLAs for Azure computing and storage, but not SQL Azure. The computing SLA says:
“For compute, we guarantee that when you deploy two or more role instances in different fault and upgrade domains your Internet facing roles will have external connectivity at least 99.95% of the time. Additionally, we will monitor all of your individual role instances and detect within two minutes when a role instance’s process is not running and initiate corrective action.”
They’re essentially pushing the SLA back onto you: you need to make sure to spin up two web servers in two different datacenters, and only then they’ll guarantee 99.95% availability. That’s 4.38 hours of downtime per year, 21.56 minutes of downtime per month. Note that they didn’t distinguish between planned and unplanned downtime.
The storage SLA says:
“For storage, we guarantee that at least 99.9% of the time we will successfully process correctly formatted requests that we receive to add, update, read and delete data. We also guarantee that your storage accounts will have connectivity to our Internet gateway.”
Note that bold part, “that we receive” – that’s because the second part of the SLA guarantees that your storage accounts will have connectivity. Nice. The three-nines rate means 8.76 hours of downtime per year, 43.2 minutes per month.
If you’re a DBA scoffing at these costs and availabilities, make sure you have your own numbers ready before your boss asks. Sooner or later, your boss is going to compare costs and SLAs in the cloud with your own internal costs and SLAs. You need answers.
My Internal Costs vs SQL Azure
A quick back-of-the-envelope calculation using a 2-cpu server with 8gb ram, SATA drives, Windows 2008 and 2 CPUs of SQL Server Standard at list price puts me around $15,000. (Yes, enterprises get dramatically discounted stuff, but enterprises don’t need SQL Azure at rack price either.)
Let’s say I use this server for five years – that’s $416 per month. That does not include:
- Power
- Connectivity costs (but neither does the Azure $9-$99 price, either. Remember that bandwidth costs extra for Azure.)
- Management (but neither does Azure, since you still have to roll some of your own utilities. Remember that Azure doesn’t support things like Profiler.)
- Backups (but neither does Azure, and no, Microsoft telling me “it’s backed up” doesn’t count.)
- Clustering or geographic high availability. I probably wouldn’t achieve three nines of uptime with this configuration, but if I wanted to go for that, I’d add a second server in another location with SQL Server’s database mirroring.
The tough part of all this is the future:
- Will SQL Azure’s costs go down? Hardware prices always go down, so it’s interesting to try to compare long-term pricing between the two.
- Will SQL Azure add more features? I can back up a locally hosted database easily, but backing up Azure is going to be a little tricky for now. If I want to add filestream data or TDE, that’s a piece of cake with local databases, but not with Azure.
- Will SQL Azure stick? If I had a dollar for every piece of technology built then Microsoft abandoned, I’d be Steve Jobs. The nice thing about developing for SQL Azure is that it’s a subset of SQL Server anyway. Worst case scenario, Microsoft abandons SQL Azure – you just light up your own SQL Server and deploy your app there anyway.
Learning More About SQL Azure
For more information about the charges that will be appearing on your credit card next year:
- SQL Azure Team Blog – the fine folks at Microsoft behind the curtain
- TSQL Support in SQL Azure – lists which commands will be supported
- Windows Azure pricing press release
- Oakleaf Systems Blog – they do great news recaps with links to the latest cloud stories.



Ha, with databases over a TB..I will not move to the cloud anytime soon. Would cost me over $100 just to move the data over for one database…wonder how long it would take assuming it is SSL
The cost itself
Bandwidth across all three services will be charged at $0.10 in / $0.15 out / GB is very similar to Amazon S3
Amazon has these for storage
Developers pay $0.150 per GB for the first 50TB, $0.140 per GB for the next 50TB, $0.130 per GB for the next 400TB, and $0.120 per GB for all remaining storage per month
and for transfers
Data transferred into Amazon S3 costs $0.10 per GB. Developers pay $0.170 per GB data transfer out for the first 10 TB, $0.130 per GB for the next 40 TB, $0.110 per GB for the next 50 TB, and $0.100 for all remaining data transferred out of Amazon S3 in a month
Well, remember, you can do unlimited transfers right now for free before it goes live, ha ha ho ho…
Plus, I like Amazon’s ability to transfer data in via USB drive: http://aws.amazon.com/importexport/
Yeah, let me mail them a raid array of 50 USB sticks hahaha
No, no, hard drives, not memory. (Although I like yours for the humor approach, heh.)
By the time they get the data it will be obsolete
We calculate 300000 things, about 6000 real time every 2 seconds…that would be really interesting to try to sync that up
Well, SQL Azure wouldn’t be for you due to the backup problems then either, because you probably wouldn’t be able to get the data back out fast enough either.
just found your blog Brent and although I’m not DBA there’s many useful informations even for the coder like me.
I am desperately looking for this answer.
I just wonder why would you need 100GB database?
) etc) and are not looking to “play in the cloud” with Azure.
In my experience – companies needing such a big DBs (or even bigger) usually have on-premises resources, which provides many more advantages (security, encryption, Oracle
And normally, for any web app (so no enterprise intranets etc just some community site) it is very hard to fill even 1GB of a DBs! Not to mention avaiable 10GBs, unless you’re storing BLOBs.
Say you’re building FLICKER like app, logically not even 1TB database is not enough, but why would you store BLOBs to a database instead a file system? Youtube or Rapidshare aren’t going that way either.
So advice me please why do you see 10GB is a limit. I would just use AZURE BLOB Rest service.
UNLESS…
There is a big “problem” of cooperation between SDS and AZURE BLOBs, in my model, that would be a showstopper.If I am missing something, and didn’t get ppl 10GB limit is too small point.
Any Advice and insight welcomed, but please provide “real world” examples, for me particularly in web app.
thanks!
Sure, one real world answer comes quickly to mind – we’ve got more than 10gb of data at StackOverflow and we’ve only been up for less than a year.
I am not sure the calculation is fair. Will anyone use a dual CPU server for a 10 GB database, in a cloud environment? I don’t think the performance is at all comparable.
It may be better to compare it with a SQL Server running in a virtualized mode, and figuring out the “break-even” point- the point at which running it an inhouse datacenter is a lot cheaper. I think the break-even is fairly low- perhaps 4X virtualization can easily beat Microsoft prices.
It’s odd to me that all this talk of limitless scaling omits completely (thus far) one of the primary issues of scaling and that is database size.
$100 for 10GB is fine, but what about 20, 30, 1000GB +?
I hope this BS about breaking each DB into a smaller size is temporary, because that’s just a flat out downer and a bit of a cop-out.
Am I missing something?
No, that certainly is disappointing.