It is great to see people catching onto the idea of federations. Recently, there has been a number of great articles and a new whitepaper that refer to how federations flip SQL Azure to “NoSQL” Azure. Yes, it is true! Federation bring great benefits of NoSQL model into SQL Azure where it is needed most. I have a special love for RDMSs after having worked on 2, Informix and SQL Server but I also have a great appreciation for NoSQL qualities after having worked on challenging web platforms. Web platforms that expose complex programmability experiences through webservices create flexible app models by handling complexity of the backend computational capacity. Best platforms deliver elasticity to handle unpredictable capacity requirements and peaks. NoSQL does bring advantages in this space by playing to a different combination of compromises (a.k.a CAP Theorem). SQL Azure is inheriting some of these properties of NoSQL through federations. Lets be more specific… Here is my list of NoSQL qualities and how federation provide us the quality.

Scale-out for Massive Parallelism

There are many models for scale-out. Some utilizing vertical partitioning… Others utilizing shared resource models… Most commercially available RDBMSs try to provide the full richness of the SQL app model with SQLs uncompromising consistency guarantees. However these implementation bottleneck as they try to maintain these guarantees and quickly exhaust capacity… With the increasing system resources spent on maintaining rich models, it is not a surprise that these implementations find themselves compromising on scalability targets. Instead, NoSQL spends little effort on sharing resources and coordinating across nodes… It compromises on consistency guarantees in favor of scale. The scale targets improve with NoSQL. Federations take a similar approach in SQL Azure. Federation decentralize and minimize coordination across nodes… With that, federations provide the ability to take advantage of the full computational power of a cluster to parallelize processing.  By federating your workload, atomic-unit focused work (a.k.a OLTP work by many of the SQL minded folks), such as “placing an order” or “shopping cart management”, get parallelized to scale to massive concurrent user load… There is little coordination between nodes needed thus the full power of the cluster is focused on processing the user workload. Federations also allow greatly parallelizing complex query processing over large amount of data through fan-out queries, such as “most popular products sold” or “best customers”. Having many nodes participate in calculating aggregates result in lower latencies.

Loosened Consistency or Eventual Consistency

Very large databases suffer from the richness of the SQL programming model sometimes because of uncompromising consistency guarantees of a ‘database’. This definition of the ‘database’ is an interesting discussion but majority vote among commercial database systems define it with the following properties; database contain a single consistent schema, allow transaction semantics on all parts of its data and adheres to ACID properties with varying isolation levels for its query processing. However loosened and eventual consistency does provide benefits. With federations, each federation member and atomic unit provide the familiar local consistency guarantees of ‘databases’. However federations compromise on strict schema requirement. You can have divergence in schema between federation members. That is fine in federations. Federations also push to a looser model of consistency for query results across multiple federation members. When executing fan-out queries, the patterns trade in regular ACID rules and isolation levels common to databases in favor of better scalability.

Lightweight Local Storage Besides Reliable Storage

One of NoSQL traits is arguably the ability to move processing close to the data. SQL Azure and other RDBMSs provide great programmability capabilities close to data. Stored procedures and TSQL provide ability to move complex logic close to data. Federations are not different. You can continue to use stored procedures, triggers, tables, views indexes and all other objects you are used to, to take full advantage of the powerful programmability surface of SQL Azure. SQL Azure databases are not lightweight local stores however. They are highly available, none volatile, replicated and protected… However there is another local store; that is tempdb. With every federation member that is scaled out, you also get a portion of tempdb on that node. It isn’t replicated so it is purely local.

Unstructured or Semi Structured Data

Relational stores provide great methods for structured data storage and query processing. If you like key value pairs, databases provide that as well. SQL Azure also support hierarchy data type and indexing as well as XML data type for semi structured data. Blob types are there for completely unstructured data.


Obviously SQL Azure databases continue to provide the consistency model that you expect between the walls of a ‘database’. The root database and federations members are all SQL Azure databases. The above list is not exhaustive and I am sure you can come up with other NoSQL properties. However it is clear that with federations, NoSQL qualities are extending into SQL Azure.