Is your database too large to fit within the limits of SQL Azure? That may be true. But with the use of Federations in SQL Azure, you can have massive flexibility through sharding, built directly in the SQL Azure platform itself.
In an Azure federation, you shard your data into multiple databases, distributing records to one instance based on a sharding key, usually an Integer or Big Integer. Each federation member supports a range of keys, and is responsible for distributing and retrieving data from the appropriate instance.
You connect to the federation through a master instance. This instance knows each of the federation instances, and the range of keys assigned to each. It is also responsible for retrieving data from the multiple instances.
There are some design considerations you need to address. Lookup tables need to be duplicated in all federation instances, if you wish to join data through queries. Also, if you have parent/child relationships, such as a purchase order and purchase order details, they should be sharded using the same range so that both are on the same instance, allowing them to be joined.
Here’s the kicker. If your application requests data that is sharded across multiple federations, you are responsible for putting everything back together again as if it were a single table. You’ll get multiple results if there are records meeting your query that cross multiple federations. Linq really comes to the rescue for this kind of situation.
The neat part of this design is that you don’t have to know where your data is stored. It is all managed, by your key assignment, across multiple databases. This can allow your data to scale out only as you need it, and still not preclude the value of storing your large data sets in a powerful Azure platform.
MSDN has a simple overview which can be found at Federations in Azure SQL Database, if you want to read more.
Cheers,
Ben