Skip to main content
Azure Table Storage is Microsoft’s fully managed NoSQL key-value store within Azure Storage accounts. It’s designed for massive scale—supporting up to 25× the capacity of a single Azure SQL Database—while providing a flexible schema: each row has two keys (PartitionKey and RowKey) plus any number of custom properties. Unlike relational tables, rows in Table Storage can have completely different sets of properties.
The image is an overview of Microsoft's Table Storage, describing it as a key-value, semi-structured database that uses tables with non-identical rows and can hold large amounts of data.

​
Relational vs. Semi-Structured Databases

Moving from relational to semi-structured (NoSQL) databases means trading rich relational features for scale and performance.
The image compares relational and semi-structured databases, highlighting features lost when moving from relational to semi-structured databases, such as relationships, views, stored procedures, indexes, and normalization.
While you lose traditional indexing, Table Storage excels at high-velocity inserts and lookups, handling millions of transactions per day with sub-millisecond reads on keyed queries.
The image is an infographic about a semi-structured database, highlighting its fast row addition, ability to process millions of transactions daily, and limited search options compared to relational databases. It also notes that some searches can be very fast.

​
Where to Create Table Storage

You can store table-style NoSQL data in Azure via: In this guide, we focus on Table Storage within an Azure Storage Account.
The image illustrates the creation of a Table Storage Database, showing that it can be created in an Azure Storage Account or Cosmos DB.
Azure Cosmos DB’s Table API offers global distribution and automatic indexing, but at a higher cost compared to native Azure Storage Table.

​
PartitionKey and RowKey

Every row in Table Storage must include these system properties: The combination of PartitionKey + RowKey is automatically indexed—queries specifying both keys return results in sub-millisecond time.
The image illustrates a data storage concept, showing rows consisting of a partition key and a row key, with the row key being unique within the partition to support efficient searching.

​
Choosing a PartitionKey

A well-designed PartitionKey evenly distributes data and request load across partitions. For example, a customer database keyed by country:
  • Canada: few customers → light traffic
  • USA: many customers → heavier traffic
  • India: very large customer base → potential hotspot
Imbalanced partitions can lead to throttling and degraded performance. Aim for partitions of roughly equal size and activity.
The image illustrates the importance of partition keys in databases, showing how they speed up searching by dividing data into equally sized and busy groups across different regions (Canada, USA, India).

​
Application Scope and Access Patterns

Relational systems let you index many columns; Table Storage limits fast lookups to PartitionKey and RowKey. Design your tables around your application’s primary access patterns.
  • Customer Management
    PartitionKey = country works if you always filter by country when retrieving data.
  • New Customer Onboarding
    If the country is unknown at insert time, a country-based PartitionKey may not fit this scenario.
Designing the wrong PartitionKey for your access patterns can lead to inefficient queries or throttling under load.
The image compares semi-structured and relational databases, highlighting that semi-structured databases are tied to a particular application, while relational databases can support many different applications.
The image illustrates the concept of a semi-structured database, highlighting the flexibility of using the right key for a customer management application, but noting it may not be suitable for finding new customers.

​
Timestamp Property

The Timestamp property is updated automatically on any row insert or update. Use it for optimistic concurrency: compare the stored timestamp before writing to ensure no concurrent modification occurred.
The image shows a data table with columns for PartitionKey, RowKey, Timestamp, Name, and City, along with a note explaining that each row has a timestamp and varying properties.

​
Browsing and Managing Table Storage

You can inspect and manage Table Storage with:
  1. Storage Browser
    Available in the Azure portal. View and edit tables, rows, and properties directly in your browser without any local installation.
  2. Azure Storage Explorer
    A standalone desktop app for Windows, macOS, and Linux. Provides rich table-management capabilities, including bulk import/export and advanced filtering.
    Download & Documentation

Watch Video