Table Storage vs Cosmos DB for Table
Key-value semi-structured data
Practice questions for this topic →
Comparison
| Azure Table Storage | Cosmos DB for Table | |
|---|---|---|
| Data model | Entities identified by PartitionKey + RowKey | Same model and SDKs (wire-protocol compatible) |
| Indexing | PartitionKey and RowKey only | All properties indexed automatically |
| Distribution | Single region (+ optional read secondary) | Turnkey global distribution, multi-region |
| Throughput | About 20,000 operations per second per table | Elastic; effectively unlimited, SLA-backed |
| Latency SLA | 10-second SLA (per Microsoft's FAQ) | <10 ms reads, <15 ms writes (P99) |
| Billing | Pay for what you use | Reserved capacity: you pay as soon as the table exists, even if idle (or serverless) |
| Consistency | Strong within the primary region | Five levels |
- Behavior differences to expect when moving: results aren't returned sorted by PartitionKey/RowKey, table names are case-sensitive, CORS isn't supported, row keys up to 255 bytes, batches up to 2 MB.
- Microsoft's own pages point to Cosmos DB for NoSQL when you need a 99.999% availability SLA, instant autoscale and automatic multi-region failover.
Exam Tips
Tick each tip once you can answer it without looking.
“Cheapest store for simple key-value data, low traffic” → Azure Table Storage.
“Table app needs global distribution and secondary indexes” → Cosmos DB for Table (same API, no code rewrite).
“Queries filter on non-key properties and are slow” → Cosmos DB for Table (automatic indexing).
“Need guaranteed single-digit-ms latency” → Cosmos DB for Table.
“Cosmos DB for Table features” → Wire-compatible with Table SDKs, automatic indexing, global distribution, five consistency levels. Trap: Microsoft points to Cosmos DB for NoSQL when you need a 99.999% SLA.
“Billing difference between the table services” → Cosmos Table reserves capacity (pay once the table exists); Table Storage pays for use. Trap: Latency: 10-second SLA versus under 10 ms reads.