Microsoft SQL Azure vs. Amazon RDS

Microsoft SQL Azure and Amazon RDS are marketed remarkably similarly. Both companies claim that their cloud database product makes it easy to migrate from on-premise servers to their database-as-a-service cloud offerings; simply migrate your schema and data to the cloud, then change a connection string in your application, and it works. They also emphasize that the same management tools used with an on-premise database can be used in the cloud. The emphasis on these similarities seems to imply that the main competition facing the two companies is on-premise offerings, rather than each other. An examination of both products shows that it is very difficult to directly compare them because the two vendors have taken an entirely different approach to architecture. The key difference arises from the fact that Amazon dedicates hardware resources to the user, while Microsoft shares resources among users. Perhaps the most significant result of this difference is the consequent disparity in pricing. However there are also other differences that may influence the decision of a consumer, and these are examined below.
Due to architectural differences, the two companies have setup their own way of charging for their offerings. SQL Azure only charges by the amount of data stored (database size). There is no cost for dedicated CPU compute time or for memory used.   In contrast, the Amazon offering charges for CPU time, regardless of the size of the database. SQL Azure can be priced between $10 - $500/month, while RDS can cost between $84 - $2100/month.  As the chart shows below, SQL Azure can cost significantly less than RDS, but it depends on the particular situation. By zooming in on the graph, you can see that RDS will actually cost less when dealing with a small CPU and memory allocation and having more than 10GB of data. This pricing difference is significant enough that many organizations will make the choice solely on price. 

Have you ever gotten this phone call? “Uh, I accidentally deleted all the customers in the customer table… in production.” That’s when point in time restore will save your life. Well, maybe not your life, but it will definitely save your job. This category was an easy one to call because RDS offers backup/restore, while SQL Azure does not.  RDS’s backup strategy allows for eight days of backups. It will also backup the logs and restore those logs to a point in time. The SQL Azure solution must be configured manually using existing on-premise tools which causes additional bandwidth charges. This is a significant drawback to SQL Azure which may prevent companies from migrating to this product.
When scaling a database you have two choices, “scaling up” or “scaling out.” “Scaling up” is adding more CPUs or memory to one box, allowing it to process requests faster. “Scaling out” is partitioning the database into smaller chunks to put it on more servers which also increases the I/O throughput. Because RDS runs on dedicated hardware, it allows you to scale-up by choosing how much processing power and memory your instance uses. Although that is expensive, it is available. SQL Azure doesn’t offer the option of scaling up. Neither product offers an in-the-box scale out solution, but third-party software is available for both.
RDS allows you to have up to a 1TB database size, while SQL Azure has a maximum capacity of 50GB. This will prohibit some companies from moving to SQL Azure.
We ran our own rudimentary performance tests from San Diego. We ran INSERTs and SELECTs against both products. RDS was significantly faster on INSERT performance, while SQL Azure was slightly faster on SELECT performance.  Since Amazon’s datacenter is in Northern California, while Microsoft’s datacenter is in San Antonio, our location may account for some of the performance difference. It might also be because RDS runs on dedicated hardware, while Microsoft is a shared service.  We were running RDS on the smallest allotment of CPU and memory, so had we been willing to pay more, RDS could be even faster. Again, that option isn’t available on SQL Azure.

RDS runs as an instance of a full-blown MySQL installation. As a result, RDS has every MySQL feature there is. RDS users can also choose a specific MySQL version to deploy. SQL Azure has a subset of the features that ship with SQL Server 2008.   While SQL Server 2008 is arguably more full-featured than MySQL; feature for feature SQL Azure is might come out ahead, users who are used to particular features from SQL Server 2008 may find that they are not available in SQL Azure.  For example, SQL Azure does not support XML indexes, CLR objects, or SQL Server Profiler.
As previously stated, both vendors enable the user to use tools that they are already comfortable with. SQL Azure can be managed using SQL Server Management Studio 2008 R2.   We were also able to connect using SQLCMD, Visual Studio 2010, and BCP. We used MySQL Workbench 5.2 to manage RDS, but all of the existing MySQL tools are available. All the tools for both products worked seamlessly and without incident. Because the cloud allows users to experiment with different technologies and platforms without the burden of management, installation, and licensing, we felt that a cloud database should provide some management software as a service (SaaS). This would allow novices to get comfortable with a new environment.  Microsoft addresses this with a Silverlight database tool called Database Manager (formally Project Houston). Using this simple and small-featured tool, anyone can get started creating tables, adding data, and creating stored procedures without installing local software.  We ran it using Internet Explorer on Windows 7 and using Chrome on Mac OSX.   While the fact that it even exists is superior to RDS, Microsoft’s tooling could be improved. For example, SQL Server Management Studio doesn’t have any designers when creating objects while connected to SQL Azure, whereas Workbench does when connected to RDS.
RDS allows you to create a standby replica of your database, but this is not done automatically. SQL Azure automatically creates standby servers when you create a new database.  RDS’s standby replicas can be in a different data center in the same geographic region (called a multiple availability zone deployment), unlike SQL Azure.   In SQL Azure, there is no additional cost for standby replicas, while RDS replicas can double or even triple the cost.
The future of SQL Azure assures an even stronger cloud database offering. Well-published roadmaps promise new features including SQL Azure Reporting Services, SQL Azure Data Sync Services, and SQL Azure OData support. With a little digging we found that Microsoft is addressing their woeful backup shortcomings and their limited maximum database size. In videos from PDC and TechEd Berlin, we found references to SQL Server Analysis Services in the cloud, SQL Server Integration Services in the cloud, and dedicated compute and memory SLAs. Meanwhile, Amazon has said that in Q2-2011, they will offer RDS using Oracle 11g as well as MySQL. While that is compelling, we expect this to raise their prices even higher due to the licensing costs. We weren’t able to find any other details on their future plans.
There are two major differences between the Microsoft SQL Azure and Amazon RDS platforms: pricing and capabilities. If price is no object and the user wants full features and high performance, then RDS is the obvious choice. If the user is more cost-conscious, SQL Azure has enough features and is good enough for many use-cases.  The two exceptions are if a user has a database larger than 50GB, or needs a mature backup system. These are not possible with SQL Azure. That said, in most instances, Microsoft developers will favor SQL Azure because of their comfort level with the T-SQL syntax and the Microsoft tooling. Ruby and Java developers who have written MySQL applications will be inclined to choose RDS.  With that in mind, perhaps these products aren’t competing with one another after all.