Azure-docs: Why Mix Table Storage and CosmosDB on a Table Storage Topic

@kdawg1406 Thanks for the question! We are investigating and will update you shortly.

Hello @kwaman
Both Table Storage and Cosmos DB are offerings to store structured NoSQL data in Azure and hence grouped together.

We will assign this issue to the content owner to evaluate and update as appropriate.

I needed the tip and the subsequent articles about the differences (one in the TOC here, and one linked in the tip that goes to the relevant Cosmos DB section). My first question was what the difference was between the two and those answered this for me.

The tip is framed a bit like an upsell so i understand why the original commenter left the feedback they did. After digging into the products i see why we need both (or at least need the capabilities/performance/pricing options of both).

It's unclear whether the CosmosDB's SDKs support the regular Azure Table Storage service.

Also, installing the Microsoft.Azure.Cosmos.Table and Microsoft.Azure.Storage.Blob packages into the same project is a huge pain - these have many similar types like CloudStorageAccount, StorageCredentials, and StorageException. This doesn't seem like a great experience 🙁

IMHO: this close to an adoption blocker. Microsoft is spending LOTS of money to attract new business.

When the docs are hard to be successful with (without deep technical understanding of Azure) this blocks or hinders adoption.

Spend the resources and make the docs simple for a person trying to on-board to be successful.

A single NOTE at the top, referencing Cosmos-db is acceptable and make sense. But after the note, give it a rest, and let the content match the title and user expectations.

Karl

I agree that this is confusing. I ended up here trying to find documentation for using Azure Table Storage without the (more expensive, and in my case unnecessary Cosmos DB offering), but pretty much every link no sends you to the Cosmos DB Table API. That's unfortunate.

Are we to conclude from this that Table Storage as we knew it will eventually simply be caught up into Cosmos DB? If not, could proper Storage Table documentation be linked to from this page?

Agree this is well confusing.
Was trying to figure out which nuget package I need for Azure Table Storage - found the old package page at:
https://www.nuget.org/packages/WindowsAzure.Storage/
It points to:
https://www.nuget.org/packages/Microsoft.Azure.CosmosDB.Table/
Which points to:
https://www.nuget.org/packages/Microsoft.Azure.Cosmos.Table

Which doesn't really say this is the package for Azure Table Storage? It says: "This client library enables working with the Microsoft Azure CosmosDB Table storage..."
Anyway, I installed it and it seems to work.

It is also really important to point out the areas that CosmosDb is not a fit. I am going to be using these tables as a data source for PowerBI, and while you may call that connection between PowerBI and CosmosDb as "Preview" it is alot like testing in production. I would really like to know if you are going to kill the table storage options in the regular storage space to boost your CosmosDb offering. If that is the path you are taking we need to know so we can evaluate other options.

The documentation on Azure Table Storage is indeed confusing..

Yeah, I can echo much of what's said here. I'm just looking for a couple of small tables to go along side some Azure Functions and I'm struggling to get started. The documentation changes come across as indicating that Cosmos DB is replacing Azure Storage Tables as most of the docs now point to Cosmos. But looking at the pricing it's not the right fit for my project, I don't need that much performance, scale or RU's.

All of this is making my getting started experience a mess, starting to wish I just made a console app and a tiny Azure SQL DB.

Azure Table Storage (link) and Azure Cosmos DB Table API (link) are two separate services where Cosmos DB Table API still provides the same functionality as the Table Storage API but with additional functionality. If there are any questions with regard to roadmap or functionality, please reach out to AskCosmosDB. They are happy to respond to questions.

Yeah, I am also confused, and in questions regarding the Azure Table storage, they say "this is owned by CosmosDB team"..., also Azure Table storage, has (almost) zero price for startes, which is about $5 / month for cosmosdb..., etc.

@Mike-Ubezzi-MSFT - Actually they are quite different in functionality if you try to use it in PowerBI (That is definitely a testing in production type solution that was provided in PowerBI. It really should be removed from PowerBI until it is ready.) I fought that for a while until I understood it was actually broken - it just looked like it was an option (It works for the regular Tables, but not Cosmos Tables)

I made the call last week to remove Azure as a possibility for unstructured table storage for our solution because of the ambiguity on the future of it on the Azure platform. I have seen this cycle from Microsoft before when the sales department has decided to drive a stake into a product and I don't want to get caught in the middle of that again.

On the links provided - if you look at the Azure Table Storage link you gave (link) most of the instructions are about how to convert to CosmosDb or how to use CosmosDb. Those of us that have been around a while know what that means. Please ask the powers that be to tell us if they are killing a product so we can stop building with it and find other solutions that will work for us. (Mike - I know that isn't you, and I don't intend to make you feel like an opponent in this. )

@MarkSiteRankSystems Thank you for the feedback. There is a Uservoice entry for this (link) and this functionality appears to be unplanned. Additionally, the ODBC Driver for Cosmos DB supports the SQL API: Connecting to Azure Cosmos DB with the ODBC driver is currently supported for Azure Cosmos DB SQL API accounts only (link).
Is there a tutorial that uses the Cosmos Table API with PowerBI? This should be pulled.
As for the documentation, I agree that all services should be detailed end-to-end in their own book, instead of this hybrid of overlapping information. Feedback has been captured.

I have the impression that there is a commercial push over Cosmos DB, leveraging confusion of users and hoping that they will activate Cosmos DB instead of Azure Table.
However this leave out users that doesn't need pricey Cosmos DB and could only use Azure Table Storage or look somewhere else to Microsoft competitors (there are competitors similar to Azure Table Storage that are well communicated and doesn't give the impression to being closed the next day).

Furthermore, this push to a common API [1] and commercially to Cosmos DB left us with broken documentation. Today I was reading StackOverflow [2] and I discovered that Tables Attribute [IgnoreProperty] documentation [3] was taken offline.

Very bad that to try do to an upselling you are instead upsetting your customer base.

[1] a common API isn't a bad thing per se, but when the API documentation is written leaving the impression that Azure Table Storage is being dismissed, is a questionable business practice
[2] https://stackoverflow.com/questions/53084652/azure-table-storage-property-attributes
[3] https://docs.microsoft.com/en-us/dotnet/api/microsoft.windowsazure.storage.table.ignorepropertyattribute?view=azure-dotnet

Happy new year! This still isn't resolved. I'm so glad I found this discussion - not feeling so alone anymore.

I've gathered that I should be able to use Microsoft.Azure.Cosmos.Table for Azure Tables - hopefully for both management of tables themselves and the data within them. Anyone know of any relevant/current samples for these cases for Azure Tables? I'm OK avoiding the entity/repository layer - I really just want to manage simple CRUD statements and DDL commands.

Haha we're in May 2020... and same issue here. I am not interested in Cosmos DB and I am using MongoDB Atlas (using the non C# Legacy UUID type btw...), just want a simple cheap Azure Table pay as you go option to store logs and as secondary backup not to lose data... for which it seems hard to find any docs. A search for "azure table" on the Azure portal points me to Azure CosmosDB... it seems impossible to find recent docs on the good old Azure Tables...
I'll guess I'll have to go somewhere else...

@alexandre-spieser You are looking for stand alone Azure Storage documentation instance. If you are looking to create a Table Storage instance, search for Azure Storage and Table will be deployed along with Blob, Queue, and File based storage options.

This document explains both options and in how Azure Table Storage is aligned as a product, it is part of the Cosmos DB service. If you are looking to see the differences: Table API in Azure Cosmos DB Vs Azure Table storage. If you are seeking a non Cosmos DB Table instance, see Azure Storage documentation.

We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.

@Mike-Ubezzi-MSFT Lot of technical docs for Azure Table Storage are pointing to CosmosDB technical docs. Explainaition is that this is same product group/team inside Microsoft hower. Azure Table storage is poorly documented.

The Azure Table Storage and Azure Cosmos DB are like Azure Storage Queue and Azure Service Bus. The former is for cheap storage and basic access operations and the latter is more expensive storage but with advanced access features. Both are useful in different scenarios. They all should be independent products.

PS. The Table API for Cosmos DB currently can't serve as a replacement for Azure Table Storage because essential functionality - sorting by PartitionKey AND RowKey is missing there (https://stackoverflow.com/questions/54946694/ordering-data-in-azure-cosmos-table-api). Such sorting is widely used by apps that use Azure Tables (because this is only sorting possibility there) and I personally don't understand why super-advanced Cosmos DB doesn't support such simple functionality via Table API?

Easier said than done. while working for MSFT for a short spell, one can understand why the docs are made this way an evolving stream of feedback is always needed!

I did want to follow up on this topic. I understand the need for Azure Table storage and Azure Cosmos DB Table API docs to be separate. This is a larger effort and something that is being discussed internally and thank you for continuing to share your thoughts and ideas on this.
Additionally, there is a sort option with Cosmos Table API as was pointed out on March 15, 2019 as an answer to the Stack Overflow thread. Please also see the Table API Sort feature request as being completed on the 17th of March. For current and future releases and release notes, please see: Azure Cosmos DB Table .NET Standard API: Download and release notes

Aside from features, there is still a huge cost difference between the solutions in some scenarios. So, CosmosDB is nice but it is not going to replace Table Storage for simple queries and low costs requirements.

Here's a guide to get up and running quickly with legacy Azure Table Storage using the latest Microsoft.Azure.Cosmos.Table NuGet package

1. Get the code sample: https://github.com/Azure-Samples/azure-cosmos-table-dotnet-core-getting-started
2. Update all NuGet packages
3. Comment out in Program.cs both lines pertaining to BasicSamples (they are the new Cosmos stuff, legacy Azure Table Storage bits are in AdvancedSamples)
4. In Settings.json set "StorageConnectionString": "UseDevelopmentStorage=true;"
5. Startup the Azure Storage Emulator
6. Run the code

Optionally
In AdvancedSamples.cs comment out the line await SamplesUtils.DeleteEntityAsync(table, customerRead);
Use Microsoft Azure Storage Explorer to connect to the emulator and view the created table and it's data

Hope that helps someone

@Mike-ubezzi-MSFT: Any thoughts on creating a migration doc on how to move from the deprecated Windows storage to CosmosDB packages? I know it's as easy as changing the namespaces - but when searching for docs, I was brought here as the top hit.