Welcome to EMC Consulting Blogs Sign in | Join | Help

Simon Munro

SQL Data Services Lacks a Compelling Business Case

As much as I avidly support cloud technologies and as much as I prefer using SQL Server, I can’t come up with a convincing reason to use or recommend SQL Data Services. SDS simply has no compelling (or obvious) business case.

The reason for this is a limitation built in to SDS of a database size from 5GB-10GB, with a promise from Microsoft that this is ‘starting point’ – implying that it may change. The reason for this limitation, I reckon, has nothing to do with storage (the difference between 5GB and 50GB is small for storage), but has more to do with the load that SDS can handle. Microsoft, by assuring us that SDS v1 addresses ‘the needs of 95% or more web and departmental application’ (sic) is hoping (estimating) that the SDS architecture will handle most web and departmental applications – and they are probably right as there are a lot of little databases out there that are not under much load. The issue is that the architecture requires that the database requirements of the application do not exceed that of a single node in the data centre. Imagine the ‘limitation’ of SDS was worded as follows:

SDS v1 is limited to the load and performance expectations of a typical quad Xeon server with 4GB of RAM.

Such a statement about the limitations would create concern and pause – the marketing spin of 5GB-10GB (as a start) is much more digestible. I posted the question in the MSDN forums based on a earlier blog entry about SDS scalability and have yet had no response from Microsoft (admittedly that may be more of a measure of my unpopularity than of any real limitations). But never mind, I am sure that Microsoft will become clearer as the launch of SDS nears – after all it is still in a private beta stage. So let’s think for a moment, as I have been struggling with for weeks, where SDS fits into a solution architecture.

Consider the table below that segments applications (markets) according to current load and expected growth:












Market Gorillas








Firstly, SDS does not cater to the needs of established enterprise applications. Enterprise applications, whether they fit in less than 5GB or not, are generally quite resource intensive (at least during peak periods) and a single average sized piece of commodity hardware is not going to cut it. Enterprises like being able to throw some heavy metal at their database in order to sort out a whole host of other performance problems quickly and easily.

Secondly, SDS does not cater for start-ups. Start-ups may initially fit within the limitations but are genetically wired to go viral and intend, from the very outset, to have massive loads as soon as possible. If you go with SDS, your only scalability path is to go on-premise – which goes against the whole idea of the cloud anyway. If a start-up hits the big time, by the time they can get a huge big box provisioned on-premise or in a co-location they may have already become yesterday’s news.

That leaves departmental applications that are low load and low growth – the sort of applications that have a handful of concurrent users which is expected to remain fairly constant over time. While SDS in particular may cater to this need, it is not a good candidate for the cloud. The effort to deploy such an application in an existing data centre or to host in using non-cloud services (shared hosting or co-location) is minimal and relatively low risk. The reasons to move these sorts of applications to the cloud are not compelling enough to put up with the problems of security, control and so on. Maybe I am downplaying this market and Microsoft has done the research that indicates that there is a lot of money to be made with small, non-growing departmental cloud applications.

Lastly, anyone building a really big, high load, high volume and high growth application has a lot of choices on how they want to store data. The cited case study provided by Microsoft (hosted exchange running on SDS) has required a lot of engineering work to partition the data across multiple SDS instances and the scalability has come at a high application development cost. It makes sense for a Microsoft division to make such an investment but external customers have more choices from multiple vendors and would obviously assess their needs rigorously.

It seems to me that the problem with SDS is not that it lacks technical cleverness or that it is a way of utilizing Microsoft’s data centre strategy to run highly available instances.

The problem with SDS is that it is not a cloud database. Definitions of the cloud may vary but they have at least one feature in common – elasticity. SDS does not offer the ability for your application to spread its load across multiple SDS instances for short periods.

If you can’t support elasticity, from the context of the application, have you really provided a cloud database? Just because from the Microsoft perspective their data centre is highly scalable (because multiple instances can be quickly spun up), it doesn’t mean that any individual application can overcome the size and load limit imposed by SDS.

Maybe I am missing something here and hopefully there is someone who can see the business case for SDS and will let me in on the secret. Until then I will keep trying to figure it out, even though I am coming up blank for now.

Simon Munro


Disclaimer: All of my opinions are based on publicly accessible information, years of experience and an interest in the cloud. I have had no access to internal information or anything else that is covered by NDA – I can only see what everyone else can on the Internet.

Published Tuesday, May 05, 2009 4:51 PM by simon.munro

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS


No Comments

Leave a Comment

Powered by Community Server (Personal Edition), by Telligent Systems