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
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 three 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.
23 Comments. Leave new
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?
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 :)) etc) and are not looking to “play in the cloud” with Azure.
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.
Our databases typically grow 15 to 20GB a year. Spliting that data across different databases would not be worthwhile. This pricing seems pretty outrageous considering drives are extremely cheap.
Thanks for looking it up.
Hey Brent,
Nice and fast calcualtions about your current DB costing under ‘My Internal Costs vs SQL Azure’.
But some things got me confused.
Here, when you say the listing price of $15,000 for the products you use for 5 years (60 months), that according to me makes 15000/60= $250 and not $416 !!!
Also, i would like to know that in compared to your on-premise infrasturure costs, what would be the price of running same applications on SQL Azure?
That might give a better picture about the ROI for long term investments.
Thanks a lot in advance.
Ah, that’s actually three years – I had a typo in there. Fixed. Fewer folks stick with the same physical server for more than 3 years, since the hardware is out of maintenance at that point.
Thanks Brant.
Can you also provide some hints about the cost of migrating the same thing onto Cloud.
Hi – Azure *is* the cloud. What cloud are you talking about, and I might be able to give you more information?
Suppose we have some DB Applications running On-Premise with 2 CPUs of SQL Server Standard, with 8gb ram, SATA drives, Windows 2008, and other configuration as you mentioned in the blog.
Now if someday i decide to move all my applications onto cloud (SQL Azure), i will need to pay something for cloud services, while i’ll be saving something on infrastructure maintenance. The infrastructure maintenance cost is around $15,000 (as you mentioned). Now if you can put some number for Cloud Services also (say, $150 per year), for running my same applications on cloud, i should be able to make crucial business decisions wheather i should continue with my existing infrastructure, or should i move onto cloud.
Ah – I don’t specialize in applications, so I couldn’t speak to that. I’m a database guy.
alright.
Thanks Brent.
Wouldn’t the cost associated with having salaried employees like SQL server DBAs and IT guys in premises be reduced with Azure Technology? I think that should be factor in as well. I guess, companies may not be required to pay to SQL Azure DBAs as much as they are paying Production SQL server DBAs because of the lesser responsibilities.
Nimesh – in theory, yes. In practice, no – you still end up needing to manage your solution. Microsoft takes away issues with server management, but they add issues with design and scale. For example, SQL Azure’s federation capability lets you put large databases in Azure, but there’s minimal management tools to do it, so it takes more administration time.
I see this was written on July 14, 2009. Has it be updated to reflect today’s status?
Also, if you are planning to migrate to SQL Azure, do you have to get Windows Azure as well?
@Ben: as of Apr 2012, SQL Azure pricing for 100MB to 10GB is $9.99 for the first GB + $3.996 for each additional. Max DB size is now 150GB, with minimum incremental pricing at $0.999 per GB.
Use of SQL Azure does not require Windows Azure. You can access it remote with SSMS or directly from your app.
Data Transfer within an Azure data center is free. MSDN subscriptions include a free 1GB database and 750 hrs/mo of a compute/web instance.
SQL Azure writes your data to three different servers (in different racks), so some amount of HA is provided.
You can now get Remote Desktop access to a Windows Azure VM, but AFAIK, you would have to either install the tools for doing backups (with compression) each time you spin up the VM, or write an app to do it.