Top 5 Differences Between Amazon RDS and Microsoft SQL Azure

Times are a-changing, and the past couple of months have witnessed a flurry of activity on the cloud computing front; namely, 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 pointedly 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 could get really difficult to choose. Here’s a list of 5 things that will help you make the right choice.

1. Target Customers: Microsoft’s target for SQL Azure (based on extensive research) is business applications running in the enterprise using databases of 5GB or less. Amazon RDS, comparatively, is more flexible and targets a larger segment of users. While with SQL Azure, you can have a database of up to 10GB, Amazon RDS allows storage of up to 1TB per database instance. Microsoft advises sharding your data in case your requirement exceeds the 10GB limit, which is not really a bad idea: Sharding your data across multiple servers will scale much better than having it all on one bloated server.

2. Support for the Cloud Platform: SQL Azure is “native” to the cloud platform. What does this mean? While MySQL (which is what Amazon RDS provisions) is cloud-capable (i.e., can be run on a cloud system without issues), SQL Azure was designed, from scratch, specifically for it. This can only mean that SQL Azure is poised to utilize the resources available in a cloud explicitly.

3. Deployment: This is where SQL Azure and Amazon RDS differ the most. While many other bloggers may lead you to believe otherwise, SQL Azure doesn’t have the concept of server/database “instances”. The “servers” that you create are more logical containers than anything else. These containers are provisioned for you exclusively, and will only host your databases. There is a one-to-many relationship between a physical node in the cloud and the servers users create — several servers created by different users may be hosted on the same hardware platform in a shared environment. That is the multi-tenanted architecture implemented by SQL Azure. However, Microsoft doesn’t plan on releasing more specifics about how servers are deployed. The biggest advantage of this model is that Microsoft is able to provide SQL Azure at very low rates. On the flip side, performance enthusiasts do not get the opportunity to tailor the system to their needs. For instance, you cannot change the cache size of your database. Moreover, having a 10GB maximum limit forces a design decision on applications that require large databases. (As previously mentioned, Microsoft advises sharding — partitioning — your data into multiple databases.)

So, how is Amazon RDS different? If you look closely enough, Amazon RDS also implements a multi-tenanted architecture (it’s highly improbable that they could afford to have a¬†separate hardware set up for each user!). But this model is implemented at a very different level than that of SQL Azure’s. Amazon RDS provisions a specialized EC2 instance to your AWS account. You can then create multiple, highly varied, instances of MySQL on that EC2 instance. Database instances can vary on the basis of storage (up to an astronomical 1TB) and compute resources (up to 26 ECUs and 68GB of RAM), and you have complete control of your DB parameters (which can be changed using the APIs exposed by Amazon RDS).

4. Compatibility with Existing Systems: For the time being at least, SQL Azure supports only a subset of the features available in SQL Server. On the other hand, Amazon RDS flaunts complete support for MySQL features minus replication. If you are a fan of MySQL, chances are that your applications will work seamlessly with Amazon RDS as well. For instance, in one of my previous posts, I had described how to set up SQLyog and MONyog for an Amazon RDS DB instance. SQL Azure features support for Transact-SQL, and existing libraries — ADO .NET, ODBC and PHP — for connection.

5. Cost/Features Ratio: With all its limitations as compared to Amazon RDS, SQL Azure is definitely a cheaper solution. A notable feature in SQL Azure 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 — all this while Amazon RDS has specifically disabled replication on its MySQL instances. Then again, SQL Azure doesn’t feature 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. Users will only experience the ‘high availability’ that this feature implies.

One last thought… So, which is it: SQL Azure or Amazon RDS? In my opinion, that would depend entirely on the type of technology you use. If you’re primarily 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’re a LAMP shop, then Amazon RDS is definitely the way to go.

Shifting to a more opinionated tone, I’d like to pose this question: What could be the primary motivation behind wanting to move one’s database to the cloud? The answer, undeniably, is scalability. As your business grows, so does your database (or so they say!). While on the surface Amazon RDS looks very glossy — they have oh-so-many features, and customizations, and options — under the hood, it boils down to one thing. Amazon RDS database instances have limited scaling capability: If you create a Double Extra Large DB Instance, and you need more compute resources (ie, CPU and memory), you’ll have to change the instance type to Quadruple Extra Large and restart your database for it to take effect. What’s more, 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 still be paying through your nose for it! SQL Azure on the other hand, allows unlimited scaling at no extra cost. All you pay for is the increased data transfer.

Conversely, SQL Azure allows only up to 10GB storage. How weird is that? My PC has a database of 14GB, which I only use for testing! If you want more storage, create a new database, shard your data across the two databases, and possibly pay double the price — all when you just needed a couple of GBs extra? Phew! I’m glad I won’t be needing to hire either Amazon’s or Microsoft’s services for a while now!

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.

+ Leave a Comment