Azure Table Storage Pricing (2026)

By Gammatek ISPL, Cloud Infrastructure Consultant,

Last updated: August 2026 | 11 min read

Gammatek ISPL manages Azure and AWS infrastructure engagements at, including storage architecture and cost optimization for + client deployments. Pricing figures below are sourced from Microsoft's published Azure rate card as of August 2026 and verified against real client billing data. This is not sponsored by Microsoft.

Table Storage's per-GB rate is the smallest part of most real bills — transactions and redundancy choices usually cost more.

Why This Matters Before You Provision Another Table

Azure Table Storage is marketed as one of the cheapest ways to store structured, schemaless data at scale — and on paper, it is. But the sticker price per GB is rarely what determines your actual bill. Teams that provision Table Storage expecting a near-free NoSQL store are often surprised when transaction volume, redundancy tier, and region-to-region egress push costs several times higher than the headline rate suggested.

If you're evaluating Table Storage for a new workload, or trying to understand why an existing bill is higher than expected, the real answer is almost never "storage is expensive." It's almost always one of three things: redundancy tier, transaction volume, or partition key design. This guide breaks down all three with real numbers, so you can price a workload accurately before you commit to it — not after the first invoice.

The Base Pricing: What Table Storage Actually Costs Per GB

<cite index="1-1">Azure Table Storage pricing ranges from roughly 4.5 cents per GB per month for locally redundant storage (LRS) up to about 12.65 cents per GB per month for read-access geo-zone-redundant storage (RA-GZRS)</cite>, with several tiers in between depending on how much geographic redundancy you need.

Redundancy Tier	What It Means	Approx. Cost/GB/Month
LRS (Locally Redundant)	3 copies within one datacenter	~$0.045
ZRS (Zone Redundant)	Copies across availability zones in one region	Slightly above LRS
GRS (Geo Redundant)	Copies replicated to a secondary region	Roughly 2x LRS
RA-GRS / RA-GZRS (Read-Access Geo)	Geo-redundant + readable from secondary region	~$0.1265

The redundancy tier is usually the single biggest lever teams overlook. Defaulting to GRS or RA-GRS "just to be safe" on data that doesn't actually need cross-region read access can roughly double or triple the storage-only cost for no functional benefit.

The Cost Most Teams Actually Get Wrong: Transactions

Every read, write, query, and batch operation against a Table Storage account is a billed transaction. For low-traffic applications this is negligible. For high-frequency workloads — telemetry ingestion, IoT event logging, high-volume application state — transaction costs can quietly become the majority of the bill, not the storage itself.

Implementation consideration (original analysis): in engagements where clients migrate a high-write logging or telemetry system to Table Storage, the most common mistake we see is writing one row per event without batching. Table Storage supports batch transactions (up to 100 operations per batch, within a single partition), and batching writes instead of sending individual transactions can cut transaction-related costs substantially for high-volume workloads — this is consistently the highest-leverage optimization available, higher than redundancy tier selection in write-heavy scenarios.

Partition Key Design: The Architecture Decision That Determines Your Bill

<cite index="2-1">Efficient partition key design is one of the most important cost levers in Table Storage</cite>, because queries that can't target a specific partition efficiently end up scanning far more data — and more transactions — than necessary. A partition key that's too coarse (e.g., a single value for millions of rows) creates hot partitions and throttling; one that's too granular can increase the number of transactions needed to retrieve related data. Getting this right at design time avoids both performance problems and unnecessary transaction costs later — restructuring a partition scheme after a workload is already in production is a far more expensive fix than designing it correctly up front.

Table Storage vs. Cosmos DB Table API: When the "Cheap" Option Isn't Actually Cheaper

A comparison worth making explicitly: Azure also offers a Table API through Cosmos DB, which uses the same data model but with different scaling, latency, and pricing characteristics (provisioned or serverless throughput rather than per-transaction billing). For workloads with unpredictable, bursty traffic, straight Table Storage's pay-per-transaction model is usually cheaper. For workloads needing guaranteed low-latency at high, sustained throughput, Cosmos DB's Table API can end up cheaper than the transaction costs of hammering plain Table Storage at scale — the crossover point depends on sustained request volume, and should be modeled with your actual traffic pattern, not assumed either way.

A Realistic Monthly Cost Example

For a representative mid-size workload — say, 500 GB of table data with moderate read/write activity — the storage-only cost sits in a fairly narrow, predictable range depending on redundancy tier chosen. What varies far more dramatically between clients is the transaction volume and egress line items, which is why two organizations storing an identical amount of data can end up with bills that differ by several multiples. This is the core reason a flat "per GB" price quote is close to meaningless without knowing the access pattern behind it.

How to Actually Control Your Table Storage Costs

1. Right-size redundancy — don't default to GRS/RA-GRS unless cross-region read access is a genuine requirement.

2. Batch transactions — group writes within a single partition into batch operations wherever the workload allows it.

3. Design partition keys around actual query patterns, not just around convenient IDs.

4. Monitor transaction volume, not just storage volume, in your cost dashboards — storage is rarely the line item that spikes unexpectedly.

5. Model Cosmos DB Table API against your real traffic pattern before assuming plain Table Storage is automatically the cheaper option at scale.

Where This Fits Into a Broader Cloud Strategy

Table Storage pricing decisions rarely happen in isolation — they're usually one piece of a larger Azure or multi-cloud architecture decision involving compute, networking, and redundancy planning across an entire environment. Getting the storage layer right is necessary, but it's most valuable as part of a full infrastructure cost review rather than a single-service optimization.

[See how our cloud infrastructure team audits and optimizes Azure/AWS environments end-to-end →