SQL Azure and limits

Quite a few folks have been asking recently about the limits we have in SQL Azure and I thought I would take some time to chat about this here.  The question varies of course by the person asking but the question inevitably goes something the following, “Hey, why don’t you guys let me have a database bigger then 10 gigs… Are you guys ever going to support big workloads or large instances?”

The short answer is yes but the truth is almost always more complicated than simple answers like this.  Frankly, while we could increase the size here it’s important to think about what raising that limit means.  It means that if we experience a failover event (hard drive dies, node reboots, you get the picture) that it may take longer to get your database up and going on another node as data may need to be caught up from other nodes on the network.  This translates into reduced availability for you in the long run and this something we try really hard to avoid.

Secondly, what about the I/O?  If your databases are getting that large then might it not be more advantageous to shard?  We’ve observed that in many workloads it does.  Granted, this may not make sense in all cases but it does in many so in a sense there is a bit of tension between the need for larger individual user db’s and enhanced support for things like sharding.

Finally, as I allude to here it would be good to hear the community’s thoughts on larger instances versus enhanced support for sharding.  We’re still debating a bit internally on which of these to tackle and in what order so this is your chance to help influence this.