This is important for multi-tenant design where we have one db per customer rather than all customers in one db.
We want to allow each customer to be able to restore their data to a point in time, take copies of there data offline to their premise, be able to write simple queries... but we don't want to reinvent all these features just to have all our customers in one db.
These features as what single dbs are best at and it seems silly to have to reinvent them just to fit an inflexible pricing model.
So we would love to be able to have dbs of any size (but particularly small dbs), where we pay for the size they occupy and/or their IO.

Could this also allow for an attach from Blob storage. This would ease the migration path.

This would also be a useful migration path, where by on-site dbs could be backed up to Azure Storage, then it would be trivial to attach or restore the db for a fully hosted option.
I can imagine offering our clients this 'off-site' backup service and then offer them a taste of cloud services by offering remote reporting etc.

Hi Mike,
I have spent at least a day going through the dozen or so causes of the dreaded initializing-busy-stopping loop. Basic diagnostics in this area are critical. At the moment this is a totally blind area. Ironically I have had to use an amazon 64 bit machine to help diagnose some of the issues and I still don't have a web role that will start yet.
A great option would be a console like feature as we see in the dev fabric that could tell us "BadImageFormatException" for xyz.dll, or filenotfound nesteddependency.dll, incorrect storage connection string etc.

This would help with functions like warehousing of reporting data to another database to keep the main transactional db performant.