Is Azure Table Storage deprecated as of now

Roman Kozlechkov 26

In my project I've so far been using table functionality from WindowsAzure.Storage. According to Nuget.org the package has been deprecated and replaced with Microsoft.Azure.Storage.Blob, Microsoft.Azure.Storage.File, Microsoft.Azure.Storage.Queue, Microsoft.Azure.Storage.Common and Microsoft.Azure.CosmosDB.Table packages. In addition to this every search through learn.microsoft for Azure Table Storage either yields articles about Cosmos DB, or quite short and uninformative articles about Azure Table Storage (no package references or API descriptions) which still advertise Cosmos DB. All this seems like a sign that
Azure Table Storage is being (or has already been) phased out completely in favor of Cosmos DB. Is the assumption correct ? If not, where can I find links to Nuget packages and API documentation related to Azure Table Storage.

2 answers

Mario Guerra 21 Reputation points Microsoft Employee

2021-08-19T16:53:14.407+00:00

Hello, I'm the Microsoft product manager for table storage and I want to clarify that Table Storage is most definitely not deprecated, it’s very much alive and supported as a service. The only things being deprecated are the original table storage SDKs and Cosmos DB Tables SDKs, but those are being replaced with new versions.

For context as to why these new SDKs exist, the packages have been updated to align with our Azure SDK Guidelines, making for an idiomatic, consistent, approachable, diagnosable, and dependable library. The new libraries use the language-specific Azure Core packages for handling requests, errors, and credentials.

To be clear, any SDK name that starts with ‘Microsoft.Azure.*’ is an older library. The new ones will have names that start with ‘Azure.*’, as in 'Azure.Data.Tables', and these new Table storage SDKs should be feature-complete in terms of parity with the old libraries. These new libraries can also target either plain table storage or Cosmos DB table storage provided they are configured with the proper endpoint.
Please sign in to rate this answer.

4 people found this answer helpful.
adriana_malea 141 Reputation points

2021-08-24T13:42:48.94+00:00

Hello,

In the response above it is stated that: "these new Table storage SDKs should be feature-complete in terms of parity with the old libraries", it is still very unclear for me in the following context: I am migrating a solution with 9 projects from .NET core 2.2 to .NET core 3.1 and I also want to replace the 'old' (not necessarily deprecated, for ex. Microsoft.WindowsAzure.Storage.Table) libraries.
In my code, there is a custom entity class derived from TableEntity (Microsoft.WindowsAzure.Storage.Table).
How should this be rewritten, considering that TableEntity from Azure.Data.Tables is a sealed class and another option would be using Microsoft.Azure.CosmosDB.Table, which I don't want, because I am not using a CosmosDb in my project?

using Azure.Data.Tables;
//using Microsoft.WindowsAzure.Storage.Table;

public class CustomEntity : TableEntity --> it yelds here that it is a sealed class
{}

Is there any example for this without involving CosmosDb libs?

Thank you!

KalyanChanumolu-MSFT 8,336 Reputation points

2021-08-26T06:46:31.777+00:00

@adriana_malea Thank you for reaching out.

You should change your custom entities to implement ITableEntity instead.

Here is an example

using Azure.Data.Tables; public class UserSubscriptionMapping : ITableEntity { public string PartitionKey { get; set; } public string RowKey { get; set; } public ETag ETag { get; set; } public DateTimeOffset? Timestamp { get; set; } public string OwningTeam { get; set; } public Guid SubscriptionId { get; set; } public string SubscriptionName { get; set; } }

Please let us know if you have any further questions on migrating to the new SDK's.
We would be happy to help.

adriana_malea 141 Reputation points

2021-09-27T13:49:21.287+00:00

Hello @KalyanChanumolu-MSFT ,

Thank you! I have used Microsoft.Azure.Cosmos.Table in the end, in order not to have such big impact in the project migration.
But I still have a big issue with DI when using [FromServices].

It yields when building with the following error:

Error Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'Microsoft.AspNetCore.Mvc.Core, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
...................
at MakeFunctionJson.FunctionJsonConverter.TryGenerateFunctionJsons()
at MakeFunctionJson.FunctionJsonConverter.TryRun()
Error generating functions metadata

I use: Microsoft.NET.Sdk.Functions" Version="3.0.13" and "Microsoft.Azure.Functions.Extensions" Version="1.1.0".

KalyanChanumolu-MSFT 8,336 Reputation points

2021-10-04T04:44:35.803+00:00

@adriana_malea This exception is related to Azure functions runtime.
Please create a new question for this issue and tag azure-functions.
It keeps the context of this thread separate from the issue and helps other forum members facing the same issue.

sadomovalex 3,631 Reputation points

2021-10-04T15:26:00.16+00:00

does this assembly version exist in your bin folder? In .Net core there is no built-in mechanism as assembly binding redirection (it is feature of .Net framework) so you have to use another approach for that: Adding a bindingRedirect to a .Net Standard library.

Aakash Sharma 6 Reputation points

2022-01-17T02:54:24.26+00:00

Thanks for clarifying it anonymous user.

I believe issue is that if you go through Microsoft documentation about the options to use a nosql key value store it only talks about the Table API in Cosmos DB and nothing about Azure table storage.

Even on the Azure and AWS comparison page, Microsoft lists CosmosDb as an equivalent service to DynamoDB but not Azure Storage Table. https://learn.microsoft.com/en-us/azure/architecture/aws-professional/services#database

Azure table storage is one of the best services in Azure and I have been using it for a very long time but based on Microsoft documentation it looks like it's a second class service.

sadomovalex 3,631 Reputation points

2022-01-17T14:49:24.127+00:00

yes it is good (and very cheap) but at the same time has quite significant limitations:

lack of LIKE operator => can't perform search by sub string. Need to introduce complex data duplication patterns with different PartitionKey/RowKey for avoiding full table scan and performance issues

only 2 system indexed columns (PartitionKey/RowKey) without possibility to add own indexes

no full pagination support (there is possibility to limit returned resultset size, but no possibility to skip number of rows)

Because of all these reasons we recently made decision to switch to CosmosDB which is more expensive but has mentioned possibilities.

Gabriel Habre 31 Reputation points

2022-02-15T08:56:21.233+00:00

We're not finding any proper solution to backup Table Storage. We'll probably resort to coding our own tools or third-party software, but since it's not deprecated and supported, perhaps you can help point to the right documentation on how to backup azure table storage.

sadomovalex 3,631 Reputation points

2022-02-15T15:17:25.153+00:00

GabrielHabre-0163, check https://github.com/Luminis-Arnhem/AzureStorageBackup. It works also for table storage

MrSmoofy 1 Reputation point

2022-12-08T21:19:28.533+00:00

Since you are the product manager for table storage can you tell me why there is no usable option to make backups of table storage with point-in-time restores? Not having a way to back up your data and restore it when you need to seems like a big missing piece.

MrSmoofy 1 Reputation point

2022-12-08T21:20:22.4+00:00

AzCopy is very slow and doesn't allow for point in time backup/restores.

Broadnax, Levi 0 Reputation points

2023-03-02T20:42:53.89+00:00

As of now, and especially at the time of writing, this response is still littered with mistakes and should not be considered accurate.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
KalyanChanumolu-MSFT 8,336 Reputation points

2020-07-09T14:42:32.473+00:00

@RomanKozlechkov-0805 I agree that there is a confusion here, let me try and clarify the same.

The SDK's for Azure Storage tables and Cosmos DB Table API are unified so that customers can start with Table storage and move to Cosmos Table API with "no code changes" when their applications evolve and demand premium capabilities like Turnkey global distribution, Dedicated throughput worldwide, Single-digit millisecond latencies at the 99th percentile, Guaranteed high availability etc

Azure Table Storage Documentation

There is a similiar discussion happening here, please follow the issue on Github for updates.
Rest assured, we heard your (and several other customers) feedback on this issue and are working on addressing it at the earliest.

If an Answer is helpful, please “Accept Answer” or Up-Vote for the same which might be beneficial to other community members reading this thread.
Please sign in to rate this answer.

1 person found this answer helpful.
KalyanChanumolu-MSFT 8,336 Reputation points

2020-07-09T14:44:04.147+00:00

Tagging @Mark Brown - MSFT to provide additional context if any

Ivan Kaliakin 1 Reputation point

2021-08-04T15:10:13.527+00:00

The customers do no not want overpay for Cosmos storage, give me back TableStorage! Why you desided to move TableEntity to CosmosDB package if it is a common part for both? You just cheating on developers. Azure functions are now consuming Microsoft.Azure.Cosmos.Table instead of Microsoft.WindowsAzure.Storage.Table .

KalyanChanumolu-MSFT 8,336 Reputation points

2021-08-04T18:09:41.54+00:00

@Ivan Kaliakin Thank you for reaching out.

Azure Table Storage and Azure Cosmos DB: Table API are two separate services. They are not combined. If you are using Table storage, you continue to pay the same cost.

If your app requires additional capabilities like higher performance and availability, global distribution, and automatic secondary indexes or a consumption-based serverless mode, you can decide to upgrade to Azure Cosmos DB: Table API.

The SDK's are combined so that you do not have to make code changes when you upgrade to Azure Cosmos DB: Table API

Pricing for Azure Table Storage and Azure Cosmos DB: Table API are different because they offer different features.

I hope this clarifies. Please let us know if you have further questions
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Is Azure Table Storage deprecated as of now

2 answers

Your answer