We need the ability to do backups. Just simple, standard backup files that we could create and download at the very least. It doesn't have to go directly blob storage or all these other suggestions. But we really, really need backups to use SQL Azure for production. Not data sync, not bcp, not SqlAzureMW -- just regular old sql server backups.

The current mechanism of specifying firewall exceptions is problematic for those without static IP addresses. Allowing permitted IP addresses to be specified by host name resolution would allow customers to use a dynamic DNS service and eliminate the need to manually update firewall rules when a new address is assigned.

Rinat Abdullin: Azure Queues are nice, but having a transactional and durable queues with guaranteed only-once delivery would be a big helper. Loosing inherent scalability is OK (just like it works out with the SQL Azure).

Suggestion in detail is here: http://abdullin.com/journal/2010/5/21/windows-azure-most-wa... more

OData's AtomPub protocol is very verbose. My calculations indicate that AtomPub multiplies Data Transfer Out bytes by a factor of 8.75. (See Querying OData.org’s SQL Azure Northwind Sample Data Service: http://oakleafblog.blogspot.com/2010/03/odataorgs-sql-azure-northwind-sample.html).

Despite the Accept-Encoding: gzip, deflate header, SQL Azure OData responses aren''t compressed. I agree with this comment by Scott Hanselman - failure to compress OData responses is LAME.