Introducing the new Azure Tables Client Libraries

Christopher Scott

If you’ve been an Azure developer for some time, you most likely have encountered the Azure Table storage service. For those not familiar, it is a service that stores large amounts of structured NoSQL data in the cloud, providing a key/attribute store with a schema-less design. For many years, it has been the primary choice in Azure providing these capabilities with rock solid stability and extremely cost effectively.

In recent years, you may have noticed that the original Table storage client SDK migrated away from the suite of storage client libraries across all languages to a Azure Cosmos DB tables package in its respective language. This change corresponded with the introduction of a new Table API in Cosmos DB which offers code and API compatibility with the existing storage service API while offering a seamless on-ramp to a set of premium features such as:

  • Single-digit millisecond latency for reads and writes, backed with <10 ms latency for reads and writes at the 99th percentile, at any scale, anywhere in the world.
  • Dedicated reserved throughput per table that’s backed by SLAs. Accounts have no upper limit on throughput and support >10 million operations/s per table.
  • Turnkey global distribution from one to any number of regions. Support for automatic and manual failovers at any time, anywhere in the world. Multi-master capability to let any region accept write operations.
  • Automatic and complete indexing on all properties by default, with no index management.

You may be wondering, how is this related to the new Azure SDKs? Well, I’m proud to announce that the new Tables client’s first beta is being released this month for the following languages: – .NETJavaPythonJavaScript/TypeScript

This means that just like all the other clients that are part of the new Azure SDK, you’ll find that it conforms to our set of guidelines which ensure it will remain idiomatic, consistent, approachable, diagnosable, and dependable across all languages.

Let’s see some examples

To introduce the new client, we’ll explore some “hello world” examples that walk through some of the more common Table scenarios. Note that these examples, as with nearly all features of the client, can target either an Azure Table storage account or an Azure Cosmos DB account.

The only change required is to create the client with the connection string for your preferred service.

For additional information about getting started, such as acquiring an Azure subscription, creating a Table account, or how to authenticate, check out the language specific links above.

Creating the table client


TableClient client = new TableClient("connectionString", "officeSupplies");


TableClient tableClient = new TableClientBuilder()


table_client = TableClient.from_connection_string(conn_str="<connection_string>", table_name="officeSupplies")


const client = TableClient.fromConnectionString("connectionString", "officeSupplies");

Creating a new table entity and adding it to the table

Table entities can contain up to 255 properties, including the 3 system properties of PartitionKey, RowKey, and Timestamp. When creating a new entity, you must provide the first two, as the Timestamp is only modified by the service. For more information, see the service documentation.


TableEntity entity = new TableEntity("markers", "01")
    { "Product", "Marker Set" },
    { "Price", 5.00 },
    { "Quantity", 21 }



TableEntity entity = new TableEntity("markers", "01")
    .addProperty("Product", "Marker Set")
    .addProperty("Price", 5.00)
    .addProperty("Quantity", 21);



my_entity = {'PartitionKey':'markers', 'RowKey':'01', 'Product':'Marker Set', 'Price':5.00, 'Quantity':21}

entity = table_client.create_entity(entity=my_entity)


const testEntity = {
      partitionKey: "markers",
      rowKey: "01",
      Product: "Marker Set",
      Price: 5.00,
      Quantity: 21 }
  await client.createEntity(entity)

Querying table entities


Pageable<TableEntity> entities = tableClient.Query<TableEntity>(filter: "PartitionKey eq 'markers'");

// Or using a filter expression
Pageable<TableEntity> entities = tableClient.Query<TableEntity>(ent => ent.PartitionKey == "markers");

foreach (TableEntity entity in entities)
    Console.WriteLine($"{entity.GetString("Product")}: {entity.GetDouble("Price")}");


ListEntitiesOptions options = new ListEntitiesOptions()
    .setFilter("PartitionKey eq 'markers'")

for (TableEntity entity : tableClient.listEntities(options)) {
    Map<String, Object> properties = entity.getProperties();
    System.out.println(String.format("%s: %.2f", properties.get("Product"), properties.get("Price")));


entities = table_client.query_entities(filter="PartitionKey eq 'markers'")

for entity in entities:
    print("{}: {}".format(entity['Product'], entity['Price']))


const strValue = "markers";
let entities = client.listEntities({
    queryOptions: { filter: odata`PartitionKey eq ${strValue}` }

let i = 1;
for await (const entity of entities) {
    console.log(`${entity.Product}: ${entity.Price}`);

Special shout out to our 2020 summer interns @meanjeekim, @eboyd23, @LibbaLawrence, and @mahdiva for their amazing work towards getting these clients shipped!


Where can I find more examples and samples?

Each project’s GitHub repository contains a comprehensive set of samples for you to explore (.NET, Java, Python, and JavaScript/TypeScript).

In addition, you can check out the Memealyzer project which demonstrates usage of many of the new Azure SDK client libraries, including Tables, across multiple languages. It also implements configuration options to seamlessly switch between Azure Storage and Azure Cosmos DB services. Note: If you don’t see you favorite language implemented yet, the project gladly accepts contributions!

Is the Azure Table storage service going away in favor of Cosmos DB’s table service?

No, it is not. The new Azure Tables client allows developers to seamlessly migrate from Azure Table storage to Azure Cosmos DB by using the Table API with no code changes and take advantage of premium capabilities. Workloads that don’t require these capabilities or prioritize a pricing model that is storage-optimized rather than throughput-optimized should continue to target Azure Table storage.

Where is Cosmos DB Table API not identical with Azure Table storage behavior?

The behavior differences are documented here.

Azure SDK Blog Contributions

Thank you for reading this Azure SDK blog post! We hope that you learned something new and welcome you to share this post. We are open to Azure SDK blog contributions. Please contact us at with your topic and we’ll get you setup as a guest blogger.


Discussion is closed. Login to edit/delete existing comments.

  • Jerome Haltom 1

    My God. What is this, the 5th iteration of the library under a different name and ownership? What next?

    • Jon GallantMicrosoft employee 0

      We understand the frustration and apologize. The new SDKs are the way forward. Here’s a good into to the new Azure SDKs

      Feel free to reach out if you want to chat.

  • Francesco Fiorenza 0

    When do you think sorting in CosmosDB using the Tables API JavaScript library will be available? At the moment data isn’t sorted by partitiionKey/ rowKey and there isn’t a sort option like the .NET library. I really hate to point this out but sorting is absolutely fundamental to any database. I can’t believe MS has overlooked this for years.

Feedback usabilla icon