Azure Table Storage

Azure Table Storage is a NoSQL key-value store for semi-structured data. It provides fast, cost-effective storage for large volumes of structured data without the complexity or cost of a full relational database. This lesson covers the data model, partitioning, querying, and when to choose Table Storage over other Azure data services.

---

What Is Azure Table Storage?

Azure Table Storage stores large amounts of structured, non-relational data. Each entity (row) is a collection of properties (columns), identified by a combination of PartitionKey and RowKey. It's schema-less, meaning different entities in the same table can have different properties.

Key Characteristics

Feature	Detail
Data model	Key-value / wide-column
Schema	Schema-less (entities can have different properties)
Max entity size	1 MB
Max properties per entity	255 (including PartitionKey, RowKey, and Timestamp)
Max property value size	64 KB for strings, 64 KB for binary
Supported property types	String, Int32, Int64, Double, Boolean, DateTime, Binary, GUID
Query language	OData filter expressions
Transactions	Entity Group Transactions (within the same partition, up to 100 entities)

---

Data Model

The Three Required Properties

Every entity in Azure Table Storage must have:

Property	Description
PartitionKey	A string that groups related entities. Determines which partition the entity is stored on.
RowKey	A string that uniquely identifies the entity within its partition.
Timestamp	Automatically managed by Azure. Records the last modification time.

The combination of PartitionKey + RowKey is the unique identifier for each entity.

Example: User Session Data

PartitionKey	RowKey	UserName	LoginTime	IPAddress
2024-01	session-001	alice	2024-01-15T09:30:00	10.0.1.5
2024-01	session-002	bob	2024-01-15T10:15:00	10.0.1.12
2024-02	session-003	alice	2024-02-01T08:00:00	10.0.2.7
2024-02	session-004	charlie	2024-02-03T14:22:00	10.0.3.1

---

Partitioning

Partitioning is the most important design consideration in Table Storage. The PartitionKey determines how data is distributed across storage nodes.

How Partitions Work

Table: UserSessions
  |
  |-- Partition: "2024-01" (all Jan 2024 sessions)
  |     |-- session-001
  |     |-- session-002
  |
  |-- Partition: "2024-02" (all Feb 2024 sessions)
        |-- session-003
        |-- session-004

Azure automatically distributes partitions across storage nodes. Each partition is served by a single node, so:

• Queries within a single partition are fast (point queries and partition scans)
• Queries across partitions require a full table scan and are slower

Choosing a Good PartitionKey

Goal	Strategy
Fast point queries	Choose a PartitionKey that is always known at query time
Even distribution	Avoid hot partitions by spreading entities across many partition keys
Batch operations	Group related entities in the same partition (required for entity group transactions)
Range queries	Use a PartitionKey that supports common range patterns (e.g., date-based)

Bad choices: A single PartitionKey value for all entities (all traffic hits one node). A PartitionKey with too many unique values when you always query across them.

---

Querying Data

Azure Table Storage supports OData query syntax for filtering entities.

Query Types (by Performance)