Compare Azure Tables and Azure SQL DB

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.

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 < 1gb of application data .

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

3 Replies

Know the answer? Post it — somebody with the same question will find it here.

Mageshwaran R5y ago
Accepted 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.
+3
Sagar Lad5y ago
Hi Stephan,

You can refer this : https://bertwagner.com/posts/deciding-between-azure-sql-and-azure-table-storage/
+1
Ben Martin5y ago
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 < 1gb of application data .
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
+2