I’ve seen many people on the web enquiring as to the difference between Azure table storage and SQL Data Services (SDS). Its a fair question, both appear in the ubiquitous Azure Services Platform slide:
[N.B. Azure table store is part of “Windows Azure” – the big horizontal bit in the picture above that underpins everything]
A few days ago Grace asked me the question in the subject of this blog entry and I couldn’t really come up with a good answer so I headed over to the SDS Getting Started forum to ask the people that know. Here’s the answer that came back from SDS Technical Evangelist Ryan Dunn:
I don't want to get into a feature by feature checklist, but rather instead say: ultimately, the trajectory of SDS has been to move more and relational features into the service. We have announced that we will be getting to schemas and constraints in the future at PDC. To this end, if you believe that you need relational features in your application - aggregates, joins, projection, etc. - you should probably continue to follow SDS. Conversely, if you do not need these features (and lots of apps don't), then Windows Azure is a perfectly fine (great) choice for you as well. I think over time the capabilities of these two services will diverge more and it will become much easier to see when to choose which.
To summarise, in time these two services will become very different. If you want to know what the main differences are today (I’m writing this in December 2008) then they are (courtesy of SDS developer Jeff Currier):
1) Joins (these are not supported in Azure tables)
2) SDS supports STS as a authentication mechanism for SOAP clients.
So, now you know! What SQL Server features would you like to see exposed in SDS? Schema-bound data and Full Text Search would be top of my list (and I believe that both are on the way).
-Jamie
UPDATE: My colleague Howard van Rooijen has a different perspective at Windows Azure – Hazy Terminology.