Well, the last blog post from my collegue was causing some attention! Lets make something very clear. We like the SQL Azure concept even if it doesn’t sounds like that in some of our blog posts. The purpose of this series of blogs is to share some knowledge that may help you when you are about to move to the Cloud, not to criticize the SQL Azure platform. The performance test from the last blog post was not a real case scenario, but rather a benchmarkt test that you can try for yourself on different SQL server configurations and disk setup to find the best setup for your demands. You can use it to compare between a SAN solution and local HDD:s, between different RAID levels, peek vs off-peek hours, or between SSD vs HDD solutions as long as you do the same test on all of your configurations. The test performed in the previous blog post was during peek hours and you’ll get some improvement running the same test in off-peek hours.
The performance measured is about the same as another SQL server connected to a SAN with synchronous replication to a secondary site. but the laptop in the test used as a reference is still about 5 times faster and it is about the same as a local SQL server with internal drives. Waits that we could maesur all had to do with High Availibilty, and of course you can’t get High Availibility on your laptop, but in SQL Azure you have 99,9% avalibility. In SQL Azure you have 2 exact kopies of the database. The conclusion is that you’ll get High Availibilty at the cost of the ultimate performance. It’s no big deal but you have to be aware of it.
If you need more performance in SQL Azure, you can use multiple databases with Federation and multiple connections.