Integrate Java Apps with Azure Table Storage

This skill builds table storage applications with the Azure Tables SDK for Java (com.azure:azure-data-tables, version 12.6.0-beta.1), which works against both Azure Table Storage and the Cosmos DB Table API through the same client surface. It covers four ways to build a TableServiceClient: connection string, shared key (AzureNamedKeyCredential with account name and key), SAS token, or DefaultAzureCredential (storage accounts only). Key concepts are TableServiceClient (manages tables - create, list, delete), TableClient (manages entities within one table), a partition key (groups entities for efficient queries) and row key (unique identifier within a partition), and an entity itself - a row with up to 252 properties, capped at 1MB for Storage or 2MB for Cosmos. Core patterns cover creating a table (createTable, which throws if it exists, or createTableIfNotExists), getting a TableClient either from the service client or built directly, and full entity CRUD: createEntity (building a TableEntity from partition/row key plus typed properties), getEntity with manual property casting, updateEntity in MERGE (update only specified properties) or REPLACE (replace the whole entity) mode, upsertEntity in either mode, and deleteEntity. Listing entities supports OData $filter expressions (partition-key equality, multi-condition AND, comparison operators like gt/ge/le) plus a $select projection to fetch only needed properties and a $top result cap. Batch operations (submitTransaction) group multiple TableTransactionActions (CREATE, UPSERT_MERGE, etc.) into one atomic call, with the hard requirement that every entity in a transaction share the same partition key. A typed-entity pattern shows implementing the TableEntity interface directly on a POJO (e.g. Product) instead of using the generic TableEntity class. Error handling catches TableServiceException for status code and message, calling out 409 (entity already exists) and 404 (not found) specifically. Best practices cover choosing partition keys that distribute load evenly, using transactions for atomic multi-entity updates, always filtering by partition key when possible, projecting only needed properties for performance, and respecting the 1MB/2MB entity size caps.

Use this skill when building a Java application that stores or queries simple key-value/NoSQL table data on either Azure Table Storage or Cosmos DB's Table API - CRUD on entities, OData-filtered listing, or atomic same-partition batch writes. It is not suited for complex relational queries or joins (table storage has no query language beyond OData filters and no cross-partition transactions), and it does not cover Cosmos DB's richer SQL/NoSQL API - that's a separate SDK (azure-cosmos) with its own querying and consistency-level features.

Input is a table name, partition/row key pairs, and entity property values, plus optional OData filter/select/top parameters for listing, with connection configuration supplied via AZURE_TABLES_CONNECTION_STRING/AZURE_TABLES_ENDPOINT for Storage or COSMOS_TABLE_ENDPOINT for the Cosmos Table API. Output is created/read/updated/deleted TableEntity objects, filtered and projected entity iterables, and atomic multi-entity transaction results (all succeeding or the whole batch failing).

Built on the Azure Tables Java SDK (azure-data-tables), working against both Azure Table Storage and Cosmos DB's Table API endpoints, authenticated via connection string, shared key, SAS token, or (for Storage) DefaultAzureCredential.

<dependency>
  <groupId>com.azure</groupId>
  <artifactId>azure-data-tables</artifactId>
  <version>12.6.0-beta.1</version>
</dependency>

Java developers building simple, high-scale key-value storage on Azure Table Storage or Cosmos DB's Table API who need entity CRUD, OData-filtered queries, and same-partition atomic batch writes without a full relational or document database.