Compare Azure Tables and Azure SQL DB

Question

When to use Azure Storage Account Tables and when not to use? When we should be using SQL DB than Azure SA Tables? Can someone enlight me with the key differences in usage perspective?

Mageshwaran R · Answer

SQL Azure is great when you want to work with structured data using relations indexes constraints etc. Azure storage table is great when you need to work with centralized structured data without relations and usually with large volumes. The Price: SQL Azure: $25.98/mo for 5GB Storage table: $21.88/m for 175 GB (without transactions or bandwidth) So when you store large volumes of data storage table is a lot cheaper... think of logging for example. The centralization: Windows Azure is a distributed environment for servers so if you save something on one machine others won't know about it therefore storage table is a good solution for centralized loggins session handling settings or whatever (keep on mind that there is latency even in one datacenter) The speed: If you design it right in many cases storage table should be faster than sql azure but it probably depends on use cases and I haven't really tested this.

Ben Martin · Answer

Azure SQL has been good to me - it works it's familiar and it's relatively inexpensive. However even though the \$5/month Azure SQL bill isn't cost prohibitive (especially with free credits :)) ideally I'd love the app to be able to fund itself via the fractions of a penny that get rounded up as part of the app's balancing logic. Azure Table Storage in comparison is dirt cheap. As of the time I'm writing this it will cost me about \$.05/month to store and access my Another option I considered is Azure SQL Serverless . This is a nice alternative because it would allow me to keep the relational structure of my data however based on my historical app usage patterns it would definitely end up costing more than Azure Table Storage. Cool service but not a good fit for my scenario. Simplicity Another reason I went with Azure Table Storage is its simplicity. Azure offers an alternative table storage option called Cosmos DB . Cosmos DB is Azure's premium table storage offering but it was overkill for what my app needed. Design Considerations for Azure Table Storage When rewriting my app's data layer there were several new things that I had to account for in Azure Table Storage. Primary Key The primary key in Azure Table Storage is made up of two columns: PartitionKey and RowKey . This composite primary key is also the clustered (and only!) index for the table. The PartitionKey in particular is important because it determines whether related rows of data will exist on the same underlying server or not. Different PartitionKey values may end up on different servers. This can be a good thing if you factor in parallel access in your design or a significant bottleneck if all of your data ends up residing on a single server. Latency There are two aspects of latency to consider. The first is how far you are from your Azure region. For me this isn't a huge deal since the only users of the app are currently in northeast Ohio so choosing to store all of the data in the same region is good enough. The bigger consideration for this app is that with Azure Table Storage you can't do any joins with your data. Well you can join in your app but you can't join in Azure itself. This means that design is critical to reducing latency since joining multiple tables of data in your app will require multiple calls to the Azure Table Storage service. This is not something that is necessarily a deal breaker just something that needs to be considered especially if coming from a relational SQL background where you are using JOINs to filter and reduce your data before it is returned to your app. Row Size Limitations NoSQL gets a lot hate for its common pattern of storing giant blobs of semi-structured data in a single field (this design makes sense when considering the latency considerations). However this becomes a delicate balancing act since each row in Azure Table Storage can only be a maximum of 1mb in size. This causes you to want to fit as much data into a single call as possible (to reduce the number of calls) while also not exceeding the 1mb row size. I hope this helps! Ben Martin

Sagar Lad · Answer

Hi Stephan You can refer this : https://bertwagner.com/posts/deciding-between-azure-sql-and-azure-table-storage/