Nigel Ellis

>  How will (if it will) the filestream type work.
FILESTREAM (see http://technet.microsoft.com/en-us/library/bb933993.aspx) will not be supported in SDS v1.   There are some unique challenges with supporting this in our SDS cluster environment.   We are however considering building a SQL RBS provider (see http://msdn.microsoft.com/en-us/library/cc905212.aspx) that would allow you to store blob data within Windows Azure and manage link level consistency from within SQL Data Services.

Nigel.

> Are you planning to charge for the total consumed space (data and indexes), or table pages only?
The exact billing model is still under discussion.  The size caps would apply to the physical database size so it would include all indexes defined.

> Are you planning to offer space compression by any chance?
This is not currently in scope for our initial release.

Nigel.

I agree there are cases where large databases are required.  Your example of Exchange backup (or other backup scenario) is a case for large blob data.  This is something supported using Azure blob storage - we will also be investigating supporting the SQL Server RBS interface which would allow seamless storage of large blobs alongside your structured data.    10GB of structured data is a great deal of information and covers our initial target application segments which shows most applications have databases in the order of < 3GB in size.

Remember any limits are just a starting point not an end.

Thanks,
Nigel.

Buzza, for concurrently we have the same mechanism available to you as SQL Server.   SQL support optimistic (timestamps or value comparisions) or pessimistic concurrency models.  The presence of the Cloud doesn't change the model at all.

Nigel.