TB vs. TiB: Why Terabytes and Tebibytes Matter in Cloud Storage Pricing
- Kevin Thomas
- Jul 6
- 11 min read
Most storage conversations use familiar words.
Terabytes. Petabytes. Gigabytes per month. Cost per TB.
That language is easy to understand. It is also easy to misread.
In cloud storage pricing, especially at backup and archive scale, the difference between a terabyte (TB) and a tebibyte (TiB) can become material. At small scale, the gap may feel like a technical detail. At hundreds of TB, thousands of TB, or petabyte-scale retention, it can change how a storage comparison looks.
That matters for anyone comparing Amazon S3, Microsoft Azure, Google Cloud, and platform providers.
It also matters because storage economics are not shaped by capacity alone. They are affected by storage class, retention assumptions, retrieval patterns, API activity, data movement, region, object count, and workload behavior.
This is one of the reasons Compare IQ exists.
Compare IQ is a pricing intelligence platform. It compares Amazon S3, Microsoft Azure, Google Cloud, and platform providers through workload-based modeling. It starts with backup and archive workloads, where retention, growth, retrieval, and long-term storage assumptions can make pricing hard to explain. The goal is simple: clearer customer conversations and more reliable decision support.
TB and TiB are not the same thing
A terabyte (TB) is decimal.
1 TB = 1,000,000,000,000 bytes
A tebibyte (TiB) is binary.
1 TiB = 1,099,511,627,776 bytes
That means 1 TiB is about 9.95% larger than 1 TB.
This is not a rounding issue. It is a unit issue.
The International Electrotechnical Commission introduced binary prefixes such as KiB, MiB, GiB, and TiB to distinguish powers-of-two measurements from decimal storage terms. NIST also describes these binary prefixes, including tebi, as part of the effort to reduce confusion in data processing and transmission.
In plain English:
A TB is how people often talk about storage.
A TiB is how many systems actually measure storage.
That difference matters when the number gets large.
The gap gets bigger at scale
At one terabyte, the difference may not seem worth arguing about.
At 500 TB, 1 PB, or 5 PB, it becomes harder to ignore.
This is where the issue becomes commercial.
If one model treats capacity as TB and another treats it as TiB, the comparison is no longer clean. A customer may believe they are comparing the same backup or archive workload across providers, but the underlying capacity assumptions may differ.
That can affect budget expectations, long-term planning, and confidence in the recommendation.
Cloud pricing language can make this harder
Cloud providers often publish storage pricing in familiar units, such as GB or TB per month. Amazon S3, Microsoft Azure Blob Storage, and Google Cloud Storage all use GB-based pricing language on their public pricing pages.
The challenge is that familiar labels do not always make the measurement assumption obvious.
Amazon S3 is a good example.
AWS uses familiar GB and TB labels on S3 pricing pages, but
AWS documentation also states that S3 storage bytes are measured in binary gigabytes, where 1 GB is 2³⁰ bytes, 1 TB is 2⁴⁰ bytes, and 1 PB is 2⁵⁰ bytes.
AWS notes that this unit is also known as a gibibyte (GiB), as defined by IEC.
In practical terms, that means S3 storage measurements can be in GiB and TiB, even when the pricing language uses GB and TB.
For experts, this may be understood.
For buyers, sellers, partners, and
customer-facing teams, it is easy to miss.
That is the problem.
Not that cloud storage is impossible to understand. The problem is that the assumptions are scattered across pricing pages, documentation, billing behavior, and workload-specific rules. The buyer is left trying to compare options while the units, tiers, metadata, requests, retrievals, and retention rules all pull the model in different directions.
Backup and archive expose the problem quickly
Backup and archive is where this issue becomes very visible.
These workloads often involve large retained datasets, multi-year storage periods, periodic retrieval assumptions, and steady growth. The difference between TB and TiB does not happen once. It can repeat across every month, every tier, every region, and every year in the model.
A backup and archive comparison may need to account for:
Storage capacity at the start of the model.
Expected data growth.
Retention period.
Storage class selection.
Retrieval frequency.
API and request activity.
Data movement.
Minimum storage duration.
Metadata overhead.
Object count.
That last point matters more than many people expect.
For S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive, AWS documents 40 KB of additional chargeable metadata for each archived object. That includes 32 KB charged at the archive storage class rate and 8 KB charged at the S3 Standard rate.
At small object counts, this may not stand out.
At large object counts, it can.
For example:
100 million archived objects, each with 40 KB of metadata, create roughly 4 TB of additional chargeable metadata.
At 1 billion archived objects, that becomes roughly 40 TB of additional chargeable metadata.
That does not mean S3 Glacier is bad. It means archive pricing requires careful modeling.
The customer should not have to discover these assumptions after the bill arrives.
The real issue is not the unit. It is trust.
TB versus TiB may look like a technical detail.
It is really a trust issue.
When a customer sees “cost per TB,” they may assume every provider is being compared on the same basis. But storage comparisons are rarely that simple.
One provider may describe capacity in decimal TB.
Another may measure in binary TiB.
A cloud pricing page may use familiar GB and TB language.
A billing report may reflect binary units.
An archive tier may include metadata overhead.
A retrieval model may change the economics.
A region selection may change the price.
A retention assumption may change the entire business case.
This is why spreadsheet-based comparison becomes risky. The spreadsheet may look precise, but the precision depends on whether the assumptions are right.
A model that misses the TB versus TiB distinction can still produce a clean-looking chart. It can still produce a confident recommendation. It can still be wrong enough to matter.
Why Compare IQ models this directly
Compare IQ was built for this kind of problem.
Compare IQ is a pricing intelligence platform. It compares Amazon S3, Microsoft Azure, Google Cloud, and platform providers side by side. It uses workload-based modeling instead of generic line-item pricing. It starts with backup and archive workloads because they expose the practical complexity of storage pricing at scale. And it helps teams create customer-facing pricing intelligence that supports clearer conversations and more confident decision-making.
That includes correctly modeling TB and TiB.
For platform providers, solution providers, and hyperscaler-aligned teams, this matters because salespeople are often asked to explain storage economics without having a team of technical pricing experts on every call.
They need a way to show the customer what is being compared.
They need to explain why the numbers differ.
They need to make assumptions visible.
They need to compare identical workloads across environments.
And they need to do that without turning every storage conversation into a custom spreadsheet exercise.
That is the role Compare IQ plays.
It helps sales and customer-facing teams move from unclear hyperscaler pricing assumptions to clear workload-based comparison.
What storage buyers should ask before trusting a comparison?
Before accepting a cloud storage comparison, ask these questions:
Does the model use TB, TiB, or both?
Are Amazon S3, Microsoft Azure, Google Cloud, and platform providers being compared using the same workload assumptions?
Does the model account for storage class, region, retention, growth, retrieval, API activity, and data movement?
For archive workloads, does the model account for metadata overhead and object count?
Does the output explain the assumptions clearly enough for a buyer, seller, or partner to defend the recommendation?
If the answer is no, the comparison may still be useful. But it should not be treated as complete.
The takeaway
TB and TiB are easy to confuse because the labels look familiar.
But at backup and archive scale, the difference can affect real storage economics.
A 9.95% unit difference may not matter much in a small test environment. Across hundreds of terabytes, petabytes, multi-year retention, and archived object counts, it can become a meaningful planning issue.
The point is not that buyers need to become storage-unit experts.
The point is that storage comparisons should make these assumptions visible.
That is why Compare IQ calculates and compares backup and archive workloads with clarity in TB and TiB across Amazon S3, Microsoft Azure, Google Cloud, and other platform providers.
Contact Purple Koru to see how Compare IQ can help your salespeople create clear, customer-facing comparisons for backup and archive workloads.
FAQ: TB vs. TiB in Cloud Storage Pricing
What is the difference between TB and TiB?
A TB, or terabyte, is a decimal unit of storage. A TiB, or tebibyte, is a binary unit of storage.
1 TB equals 1,000,000,000,000 bytes.
1 TiB equals 1,099,511,627,776 bytes.
That means 1 TiB is about 9.95% larger than 1 TB. The difference can seem small in a simple example, but it becomes material when storage environments reach hundreds of terabytes, petabytes, or multi-year archive scale.
Why does TB vs. TiB matter in cloud storage pricing?
TB vs. TiB matters because storage pricing comparisons can change when one model uses decimal storage and another uses binary storage.
A buyer may think they are comparing the same amount of storage across Amazon S3, Microsoft Azure, Google Cloud, and a platform provider. But if one model treats the workload as TB and another treats it as TiB, the comparison is not aligned. At large scale, that unit difference can affect budget planning, price comparisons, and customer expectations.
Is 1 TiB larger than 1 TB?
Yes. 1 TiB is larger than 1 TB.
1 TiB equals about 1.0995 TB. In practical terms, that means 1 TiB is about 9.95% larger than 1 TB. At 100 TiB, the difference is about 9.95 TB. At 500 TiB, the difference is about 49.76 TB. At 5 PiB, the difference is about 629.50 TB.
Why do people say TB when systems may measure TiB?
People often say "TB" because it is the familiar business term for storage. Systems often measure storage in binary units because computing systems have historically used powers of two.
This creates a language gap. A customer may talk about 500 TB of storage, while a storage system, a billing report, or a pricing model may use binary units. That gap needs to be visible in any serious storage pricing comparison.
How much larger is a tebibyte than a terabyte?
A tebibyte is about 9.95% larger than a terabyte.
The formula is simple:
1 TiB = 1,099,511,627,776 bytes
1 TB = 1,000,000,000,000 bytes
So the difference is 99,511,627,776 bytes per TiB. That difference compounds as storage environments grow.
Why does the difference become important at petabyte scale?
The difference becomes important at the petabyte scale because a 9.95% unit gap can translate into hundreds of terabytes of capacity.
For example, 1 PiB equals 1,024 TiB, which is about 1,125.90 TB. A 5 PiB environment equals about 5,629.50 TB. That is about 629.50 TB more than the 5,000 TB many people may assume when they hear “5 PB.”
For backup and archive workloads, that difference can affect multi-year cost models, retention planning, and customer-facing pricing conversations.
Does Amazon S3 use TB or TiB for storage measurement?
Amazon S3 pricing pages often use familiar GB and TB labels, but AWS documentation defines S3 storage measurement in binary terms.
That means S3 storage measurements can be in GiB and TiB, even when the pricing language says GB and TB. For storage buyers, the key point is not the label alone. The key point is whether the comparison model uses the same unit assumptions across Amazon S3, Microsoft Azure, Google Cloud, and platform providers.
Why can S3 Glacier pricing be hard to compare?
S3 Glacier pricing can be hard to compare because the final cost depends on more than just the advertised storage rate.
A proper archive model may need to account for storage class, retention period, retrieval patterns, request activity, region, object count, and metadata overhead. S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive also include chargeable metadata per archived object, which can matter at scale when there are many small files.
That is why archive pricing should be modeled as a workload, not just as a cost-per-TB line item.
What is the 40 KB metadata charge in S3 Glacier?
The 40 KB metadata charge refers to additional chargeable metadata associated with each archived object in S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive.
At small object counts, this may not stand out. At large object counts, it can become meaningful. For example, 100 million archived objects with 40 KB of metadata each creates roughly 4 TB of additional chargeable metadata. At 1 billion archived objects, that becomes roughly 40 TB.
This is one reason object count matters in backup and archive cost modeling.
Why is backup and archive especially sensitive to TB vs. TiB?
Backup and archive workloads are especially sensitive to TB vs. TiB because they often involve large datasets, long retention periods, steady growth, and periodic retrieval assumptions.
A unit difference may repeat across every month, every region, every storage class, and every year in the model. That can make a comparison look cleaner than it really is if the model does not make TB and TiB assumptions clear.
What should storage buyers ask before trusting a cloud storage comparison?
Storage buyers should ask whether the model uses TB, TiB, or both.
They should also ask whether Amazon S3, Microsoft Azure, Google Cloud, and platform providers are being compared using identical workload assumptions. A reliable comparison should account for storage class, region, retention, growth, retrieval, API activity, data movement, metadata overhead, and object count when those factors apply.
A clean-looking spreadsheet is not enough. The assumptions behind the model need to be clear.
Why is workload-based modeling better than a simple pricing calculator?
Workload-based modeling is better because storage cost depends on how the workload behaves, not just the published cost per TB.
A simple pricing calculator may show a storage rate. A workload-based model can compare identical backup and archive scenarios across Amazon S3, Microsoft Azure, Google Cloud, and platform providers. That makes it easier to explain why costs differ and what assumptions are driving the comparison.
How does Compare IQ handle TB vs. TiB?
Compare IQ calculates and compares storage workloads with TB and TiB assumptions made clear.
Compare IQ is a pricing intelligence platform. It compares Amazon S3, Microsoft Azure, Google Cloud, and platform providers through workload-based modeling. It starts with backup and archive workloads, where capacity, retention, retrieval, metadata, object count, and multi-year assumptions can materially affect the comparison.
The goal is to give salespeople and customer-facing teams clear, customer-ready pricing intelligence instead of relying on manual spreadsheet analysis or technical bottlenecks.
Who is Compare IQ for?
Compare IQ is for platform providers, solution providers, partners, and hyperscaler-aligned teams that need to explain storage pricing clearly to customers.
It helps teams compare identical workloads across Amazon S3, Microsoft Azure, Google Cloud, and platform providers. The first workload module focuses on backup and archive, where storage pricing complexity is highly visible and customer decision pressure is high.
Why should sales teams care about TB vs. TiB?
Sales teams should care because TB vs. TiB can affect the credibility of a storage pricing conversation.
When customers ask for a cost comparison, they expect the same workload to be compared on the same basis. If the unit assumptions are unclear, the seller may struggle to explain the numbers or defend the recommendation. Compare IQ helps salespeople show the assumptions clearly and support more confident customer conversations.
How can Compare IQ help with backup and archive pricing conversations?
Compare IQ helps sales teams create clear comparisons for backup and archive workloads across Amazon S3, Microsoft Azure, Google Cloud, and platform providers.
It models identical workloads, accounts for key pricing assumptions, and generates customer-facing outputs that salespeople can use in real conversations. That helps reduce reliance on technical teams and gives customers a clearer view of how storage economics change across providers.
What is the main takeaway from TB vs. TiB?
The main takeaway is that TB and TiB are not interchangeable.
At small scale, the difference may feel minor. At backup and archive scale, especially across hundreds of terabytes or petabytes, the difference can become a real planning issue. Storage buyers do not need to become unit experts, but they do need comparisons that make the assumptions visible.
Compare IQ was built to make those assumptions clearer across Amazon S3, Microsoft Azure, Google Cloud, and platform providers.
How can I get help comparing backup and archive storage costs?
Contact Purple Koru to see how Compare IQ can help your salespeople create clear, customer-facing comparisons for backup and archive workloads.
Compare IQ gives teams a way to model identical workloads across Amazon S3, Microsoft Azure, Google Cloud, and platform providers, with TB and TiB assumptions made clear.
Comments