Knowing when to choose Windows Azure Table Storage or Windows Azure SQL database

Question Recommended Technology
Are you trying to keep costs low while storing significantly large data volumes in the multi-terabyte range? Use Windows Azure Table Storage
Do you require a flexible schema where each data element being stored is non-uniform and whose structure may not be known at design time Use Windows Azure Table Storage
Do your business requirements require robust disaster recover capabilities that span geographical locations?

Do your geo-replication needs involve two data centers that are hundreds of miles apart but on the same continent?
Use Windows Azure Table Storage
Do your data storage requirements exceed 150 GB and you are reluctant to manually shard or partition your data? Use Windows Azure Table Storage
Do you wish to interact with your data using restful techniques and you don’t want to put up your own front-end Web server? Use Windows Azure Table Storage
Is your data less than one 150 GB and involves complex relationships with highly structured data? Use Windows Azure SQL Database
Do your data requirements involve complex relationships, server-side joins, secondary indexes, and the need for complex business logic in the form of stored procedures? Use Windows Azure SQL Database
Do you want your storage software to enforce referential integrity, data uniqueness,primary and foreign keys? Use Windows Azure SQL Database
Do you wish to continue to use your SQL reporting and analysis tooling? Use Windows Azure SQL Database
Does your database system relied heavily on stored procedures to support business rules? Use Windows Azure SQL Database
Do your business applications currently execute SQL statements that include joins, aggregation, and complex predicates? Use Windows Azure SQL Database
Does each entity or row of data that you insert exceed 1 MB? Use Windows Azure SQL Database
Does your code depend on ADO.NET or ODBC? Use Windows Azure SQL Database

Comments (1)

  1. Ken Smith says:

    I have a slightly different take. The impression I get is basically, "Try really hard not to use Azure Table Storage". It's not just a "No-SQL" data-store, it's a particularly stunted, handicapped, and very-low-featured instance of a No-SQL store. About the only thing I've heard good about it is that you can put lots and lots of data into it very quickly, and with minimal storage fees. However, the very strong impression I get is that you basically can't hope to get that data back out again unless you're lucky enough to have a use-case that magically matches its Partition-Key/Row-Key storage model. If you don't – and I suspect very few people do – you're going to be doing a lot of partition scans, and processing the data yourself.

    Beyond that, Azure Table Storage seems to be at a dead-end in terms of development. If you look at the "Support Secondary Indexes" request on the Azure feedback forums (…/396314-support-secondary-indexes), you can see that support for Secondary Indexes was promised as far back as 2011, but no progress has been made. Nor has any progress been made on any of the other top requests for Table Storage.

    Now, I know that Scott Guthrie is a quality guy, so my hope is that all this stagnation on the Table Storage front is a preface to Azure fixing it and coming up with something really cool. That's my hope (though I have zero evidence that's the case). But for right now, unless you don't have a choice, I'd strongly recommend against Azure Table Storage. Use Azure SQL; use your own instance of MongoDB or some other No-SQL DB; or use Amazon DynamoDB. But don't use Azure Table Storage.

Skip to main content