Extend Table Storage Property Limit
Currently, Azure Tables only support 255 properties (columns) on a single entity (row) and a max row size of 1MB. This should be greatly extended (e.g. 10x+), particularly since Azure does not offer Join query support. Without Join support, devs are forced to span large data structures across multiple tables. When querying the data, devs have to manage this extra complexity as well as suffer the performance penalties of querying against N tables and then performing their own post-join operation. Azure Tables scale great in one dimension (# rows), but horribly in the other (# columns). While Azure Tables should *definitely* increase their LINQ operator support, greatly extending this property limitation removes a great deal of stress. Also, along with this, devs should be able to Select only certain columns, rather than always having to return entire rows.
This ask is currently on our backlog and will be prioritized accordingly. We will update when the status changes.
Maxime Beaudry commented
I'm all for making the size limit a bit larger, it does force unwanted extra complexity on a key value pair store. The limit can still be reasonable, just large enough not to force devs to consider breaking down properties into chunks for the sake of limitation.
Jan Jirka commented
I always find it funny when I look at the dates - this was created in 2011, in 2016 it moved to backlog and it's now 2019. I hope I don't die before it goes into iteration.
Lajos Marton commented
My most painful point is the 32Kb limit of property size. If I use it as a key - value store (and why not, actually it is), then I can't use the 1mb row limit, if I have only one key and one value in a row and value must be maximum 32Kb what is very tiny :(
Tony Wang commented
The limits like 255 properties, 64KB for each column, 1MB for a row are quite ugly. I know there will always be a limit(s), but not that kind of small and low.
I have real world scenario which force me to build a much complex walk-around which solve the problem but hurt the performance.
Please raise those limits to something much larger.
Jon von Gillern commented
You want Joins? You're trying to ***** a bolt with a jackhammer. Azure table storage is essentially a key-value store. It doesn't do joins. It takes a PartitionKey and a RowKey and gets you the data ridiculously fast, even if it is replicated half way across the country and it is dirt cheap. I have 10-15 million of transactions a month and it costs me less than 5 bucks/month. I'd be paying through the nose if I had a SQL server that could perform the way Azure Table storage does.
When it comes to data storage you get to pick 2 of 3 - cheap, fast, flexible. Azure Table storage is cheap and fast.
If you need joins, you're going to have to pick a different tool, or deal with the added complexity of adding entities under multiple keys.
Rune Synnevåg commented
Under review since 2011??
Ben Callister commented
After working with Azure Tables for a long time now, i have realized the great need for this feature!