Top 5 Differences Between Amazon RDS and Microsoft SQL Azure

There has been a flurry of activity over the past couple of months on the cloud computing front, primarily related to Microsoft SQL Azure and Amazon RDS. Touted as the harbingers of a new era—the era of Relational DBMS-as-a-Service (DBaaS)—these latest offerings reassert the fact that databases are now part of the utility model of cloud computing.

For those planning on an early adoption, even with just two significant products (no one seems to have noticed Joyent’s Accelerator for MySQL), it can be very difficult to choose. Here’s a list of five things that will help you make the right choice.

Target Customers

Microsoft’s target for SQL Azure is business applications running in the enterprise which are using databases of 5 GB or less. Amazon RDS is comparatively more flexible and targets a wider segment of users. Although with SQL Azure you can have a database as large as 10 GB, Amazon RDS allows storage of up to 1 TB per database instance. Microsoft advises sharding your data if your requirements will exceed their 10 GB limit. This isn’t a bad idea: Sharding your data across multiple servers will scale much better than having it all on one bloated server.

Support for the Cloud Platform

SQL Azure is native to the Cloud platform. This means that while MySQL—which is what Amazon RDS provisions—is Cloud-capable (i.e., it can run on a cloud system without problems), SQL Azure was designed specifically for the Cloud. This would suggest that SQL Azure is poised to utilize explicitly any resources available in a cloud.


Deployment is where SQL Azure and Amazon RDS differ the most. While many people may lead you to believe otherwise, SQL Azure doesn’t quite grasp the concept of server/database instances. The servers that you create with SQL Azure are basically logical containers. These containers are provisioned exclusively for you, and will host only your databases. There is a one-to-many relationship between a physical node in the Cloud and the servers you create—several servers created by different users may be hosted on the same hardware platform in a shared environment. This is known as multi-tenant architecture. The biggest advantage of this is that Microsoft is able to provide SQL Azure at very low rates. However, you can’t tailor a system for better performance. For instance, you can’t change the query cache size. Moreover, having a limit of 10 GB forces you to make design decision for applications that require large databases, such as splitting data between multiple databases.

Amazon RDS also implements a multi-tenanted architecture, but this is done at a very different level than with SQL Azure. Amazon RDS provisions a specialized EC2 instance to each AWS account. You can then create multiple, highly varied instances of MySQL on your EC2 instance. Database instances can vary on the basis of storage (e.g., up to 1 TB) and computing resources (e.g., up to 26 ECUs and 68 GB of RAM), and you have complete control of your database parameters. This can be changed using the APIs provided with Amazon RDS.

Compatibility with Existing Systems

For now, SQL Azure supports only a subset of the features available with SQL Server. Amazon RDS flaunts complete support for MySQL features, with the exception of replication. If you already use MySQL, your applications will probably work seamlessly with Amazon RDS. For instance, in one of our previous posts, we described how to set up MONyog for an Amazon RDS database instance. SQL Azure features support for Transact-SQL, and existing libraries (i.e., ADO .NET, ODBC and PHP) for connection.

Cost to Features Ratio

With all of its limitations in comparison to Amazon RDS, SQL Azure is definitely a cheaper solution. A notable feature is that databases are automatically replicated across multiple systems providing for read scale-outs, as well as a transparent fail-over mechanism in case of hardware failure. By contrast, Amazon RDS has specifically disabled replication on its MySQL instances. Then again, SQL Azure doesn’t offer a parallel to the unique on-demand snapshot-based backup method offered by Amazon RDS. Data in SQL Azure is automatically backed up and restored when a disaster occurs. This is transparent to the user, which does provide the high availability that this feature implies.


Choosing between SQL Azure or Amazon RDS would probably depend the most on the type of technology you use already. If you primarily have a Microsoft shop, then SQL Azure will be a better choice, as the technology would be familiar—you’ll get Visual Studio integration, support for .NET applications, T-SQL, etc. On the other hand, if you have a LAMP shop, Amazon RDS is definitely the better choice.

If you’re still not sure which to use, consider what is your primary motivation to move your database to the Cloud. It’s probably for scalability. As your business grows, so does your database. Although Amazon RDS has many features, customizations, and options, scalability is what’s most important. Amazon RDS database instances have limited scaling capability. For instance, if you create a Double Extra Large DB Instance, and you need more computing resources (i.e., CPU and memory), you’ll have to change the instance type to Quadruple Extra Large and restart your database before it will take effect. What’s worse, if you’ve created a Quadruple Extra Large DB instance and your DB instance is not actually using all of the resources available, you’ll be paying much more than you should. SQL Azure on the other hand, allows unlimited scaling at no extra cost. All you pay for is the increased data transfer.

Still, SQL Azure allows only up to 10 GB of storage. If you want more storage, you’ll have to create a new database, shard your data across the two databases, and possibly pay double the price—even if you need only a few gigabytes more.

Again, it depends on your technology preferences, how much flexibility you need, and what is your budget. You have to consider all of this when choosing the best Cloud platform and database system for your situation, and when configuring whatever you choose.

For more information on SQL Azure, visit
For more information on Amazon RDS, visit


Add yours
  1. 1

    AFAIC Amazon pricing is off by a factor 10. Microsoft offers a smarter pricing model and setup. And I thought I would never say this, but unfortunately I’m on mySQL. So unless Amazon gets a bit smarter with its pricing, no clouds for me.

  2. 2

    Actually, you’re focusing a lot on what is coming out on day 1 re: SQL Azure. There will be new sizes available for Azure databases within the next year that will make them competitive to what you can do with mySql/Amazon. They wanted to limit the size of databases coming out the gate since its still in beta. And as you pointed out, developers do need to start considering how to shard out – MS has plans in place to try and make this relatively seemless for the developer.

    Subset of TSQL – yes, but the differences are very small and would affect less than 2% of development. Most of the features that are unavailable in T-SQL relate to being on a “shared” instance of SQL Server and are not available for obvious security reasons.

    Agree with LAMP vs. MS Shop analogy for now, but even PHP developers can take advantage of Azure right now. The connectivity will only grow.

    Just remember – Azure is only coming out of beta in Q1 of 2010. There’s a lot in the pipeline that will make a lot of your comments moot within the next year.

    • 3
      Sayan Chaliha

      You get the picture!

      Thanks for your valuable insight! Of course, I do realize that SQL Azure is not even out of beta yet, and yes, I’m definitely looking forward to what Microsoft has to offer in the future. But, very frankly, I really wanted to concentrate on the “now” instead of speculating. So I went ahead and compared the CTP version of SQL Azure with Amazon RDS. Justification: Take into consideration Amazon RDS’s release announcement… I knew at that point that SQL Azure was in the making, but I had no idea that Amazon was up to anything like it. Not everybody is waiting around for somebody else. And not to mention, this post will be outdated within a couple of months, I’m sure!

  3. 4

    SQL Azure on the other hand allows unlimited scaling at no extra cost. All you pay for is the increased data transfer.

    If I understand this correctly, under the hood I’ll get super-performant virtual machine, which will handle all my sql queries, say, even 10 thousands per second.
    The only thing I pay for is increased traffic?

    If this is true, it would be awesome. Can you provide me some resources on this please?
    Traffic usually gets lower at night, and no matter how strong Amazon RDS server I choose, it is still one and only one server, and without replication, isn’t able to handle high concurency sites (some smaller one requires say 10 DB HW servers).

    I am willing to pay whatever the cost for SQL Azure, if they promise me parallel queries and super-efficient DB engine. But I don’t know if that is the case, because they were saying that to increase query parallelism you need to scale out (sharding). But I’m scaling out because of DB size limit, I don’t want to scale out because of their system is weak. Please, elaborate.

    In that case, Amazon wins, as I can buy more powerful server than what AZURE SQL provides as their “top maximum”.

    2nd thing, I think changing DB settings is against databases in the cloud. Question is, why would I like to put my DB to cloud? Answer is, because of maintance.
    If I need to check it, set it up, and do various other things, I can do it on my dedicated host as well!


    • 5
      Sayan Chaliha


      I am going to refer you to this discussion I had with the MS guys at the SQL Azure forum. I asked the very same question, and that is what they had to say in reply: Unlimited scaling at no extra cost! I was pretty surprised myself. However, off the top of my head, I can’t remember links to such references elsewhere. I’ll have to scour the SQL Azure documentation again.

      As far as DB settings go, I partially agree with you. Yes, of course you’d want to relieve yourself of the burden of tuning a DB. And that is a major advantage of cloud-based DBaaS. You also have to agree that the scalability offered could be quite a motivation for using DBaaS. But a certain section of power-users and performance enthusiasts (aka, the geeks, if you may) would hate to relinquish that control in lieu of having their DBs run in high performance environments such as cloud.

  4. 6

    I wonder why it’s simply not possible to scale-out a relational DBMS without sharding on appication level? Replication is no option in write-heavy environments. So this ‘SQL Azure scales unlimitedly’ is only the half of the truth or not? Especially with high volume databases. If you watch Facebook, Digg and other big internet companies, they all are not able to use the relational features in such big environments. Solution one is sharding on application level and drop usage of relational features. Solution two is switching to distributed data storage (Cassandra, HBase or other semi structured data stores). So how can they claim that their new shiny relational DBMS in the Cloud can scale-out?

  5. 7

    Amazon RDS is simply a virtual machine that has MySQL installed on it. It does not have anything to do with cloud. You gotta increase the storage manually, you gotta buy more memory + cpu speed if your db increase. Microsoft SQL Azure is the only true cloud database.

  6. 9
    John Sterrett

    While the header says this article was updated on April 1st, 2017 it doesn’t seem like the Azure content has been updated in a very long time. For example, you can now have a 4TB database.

    Azure SQL Database and features are more aligned with features in SQL Server. You can see the compatibility list yourself at

    The link for more about Azure SQL Database is also no longer correct. You find more information at

    You can also select MySQL as a managed service now as well. You can find more on MySQL Azure Databases at

    • 10

      Hi John,

      Agree with your point. This blog was accurate at the time of publication which is 06 January 2010. However, there were some changes undertaken on the blog page due to which it mentions April 01, 2017 as the updated date. We will be coming up with a more updated version that accurately captures details/information on Azure databases.

      Apologies for the confusion.

      Best Regards,

+ Leave a Comment