Alternatives to Azure Table Storage

Although Azure table storage does not support secondary indexes, and does not have the feature set of SQL, it is not trying to solve the same problem.

I would avoid SQL Azure (or whatever it's called now) and focus on building a data layer that uses what Azure is good at (blobs, tables, and queues).

We have found table storage to be more than adequate for a large production solution. It has gotten a lot better over the last 18 months or so. The v2 of the .NET client library is much better than v1.

As with most applications, a direct port of the architecture onto a cloud platform is rarely a good idea. Rethinking the way that you have solved previous business problems with a solid understanding of what's available in the cloud is the only path to success.

I agree with a previous post that something like Lucene could be good if you need to index a lot of data. We find that using tables and blobs well we are able to make do without, but it's definitely an option in your toolbox.

We have gone through a similar situation and have researched several options, which offers Azure and nosql options.

The measure we have taken has been to use Azure Blob Storage and Lucene.Net. We serialize our objects in Json and then save them in AzureBlobs.

We use Lucene.Net to create indexes, Lucene.Net returns the data we need to get the blobs that contain the data we want to search. We do not have a development in production yet with this combination but in the tests we have done it is working very well.

Maybe little bit off topic.

There are several use cases, where ATS is great tool.

One case is storing meta data you usually store as XML (JSON) serialized objects within your regular RDB. These are data, which don't need indexing over, but are structured. For example all client meta data. The reason to use rather ATS than SQL is the ability of the ATS to add, remove column of such data on the go. So whenever you change the meta data structure you don't need to loop through all client records, deserialize the XML (JSON), recreate the data tree, serialize it into XML (JSON) and store it back into the table. This is perfect. The down side of the coin is you must keep flat structure of the meta data instead of tree structure you can achieve using classic XML (JSON) serialization.

Second case is storing the data from your RDBM you don't need in case there are too many of them. It could be for example list of transactions in banking system older than 5 years. These are the data you actually need to store, but not in active form. These data would slow down your joins/where conditions and you don't need them at daily base. You can still get these data back or move them into another RDBM for offline analysis made once per year. Storing the data in ATS is also much more cheaper than leaving them inside of RDBM.