Add support for gzip and/or deflate on Table Storage
I noticed that the Storage team has gone to great lengths to reduce bandwidth usage by switching to JSON. Take this to the next logical step and add support for the Accept-Encoding header in the client libraries and have the server return content gzipped or deflated. JSON compresses quite nicely, especially if the entities returned from a query are similar, which they nearly always will be if you're querying on PartitionKey and RowKey
This is an interesting idea. The ask is currently on our backlog and will be prioritized accordingly. It is unlikely to happen in the coming year due to other priorities, however we will update when the status changes.
Remco Huijser commented
Really like this idea: we are using table storage to store a lot of statistical data which we want to transfer as quickly as possible.
I agree. At least for external calls to the REST API (not internal to azure). Table Storage is an awesome backend for large scale mobile and SPA apps. However bandwidth is quite expensive and gzip on average results in a 7-8x reduction for JSON query results. The large payload size also takes significantly longer to download and is less responsive.
Understand turning on gzip could increase server load that's why perhaps just for external client IP's. As the internal network has plenty of bandwidth and is low latency it seems a non issue.
The server load thing is probably a reason why it's not supported - all adds up at scale. I'd be willing to pay a higher storage transaction rate as the bandwidth savings alone would offset any cost. At least for blob storage the client can manually gzip the files when uploading and set the correct meta data.
Just gziping HTTP GET's would suffice.