Summary
Separating data reduction from tiering, snapshots, and clones makes storage efficiency guarantees easier to evaluate and flash capacity planning more accurate.
Consider this scenario: You make a storage purchase. The platform comes with an efficiency guarantee, and the capacity model is built around it. The hardware order is sized accordingly. Then the utilization data in the management console and the actual storage footprint start telling two different stories. Six months after your purchase, the capacity review comes back wrong. Why?
The issue is not that the technology failed. It’s that the efficiency ratio in the guarantee and the efficiency ratio that determines how much primary flash your organization actually needs are calculated differently.
That distinction matters more than many buyers realize. Two vendors can quote very different storage efficiency ratios for the same workload and both can be telling the truth. What changes is the definition of efficiency inside the guarantee, and that definition shapes everything downstream: how much hardware you buy, what you pay for power and cooling, how much rack space you need, and what the next expansion conversation looks like.
If that definition is different from what you assumed, the surprise does not show up in the quote. It shows up later, when changing course is more expensive.
Here’s a breakdown of what counts, what doesn’t, and what to ask before you accept any efficiency claim at face value.
What data reduction actually means
When a storage vendor says data reduction, the claim should mean something specific: For every 5TB of logical data you write, you consume 1TB of physical flash capacity. The mechanisms that produce this outcome are:
- Inline deduplication: Removes identical data blocks before they’re committed to storage
- Compression: Reduces the size of individual data blocks by encoding them more efficiently
- Pattern removal and zero-block detection: Eliminates predictable patterns before they consume capacity
Applied inline, before data hits physical media, those mechanisms produce genuine on-array data reduction. The result is a smaller physical footprint for the same logical data, which shows up as:
- Fewer drives
- Less power consumption
- Less rack space
- Lower acquisition cost for equivalent usable capacity
When a storage efficiency guarantee covers those mechanisms and nothing else, the claim is clean. When it covers other things in addition—or instead—the definition needs scrutiny.
What data tiering is, and why it’s different
Data Tiering works on a different principle. It identifies data that has not been accessed recently and moves it from primary flash to a lower-cost storage tier, typically object storage. In simple terms:
- The hot, frequently accessed data stays on flash.
- The cold, infrequently accessed data moves to a lower-cost bucket.
This is a legitimate and often sensible capability. For workloads with a significant portion of cold data, tiering can meaningfully reduce the amount of primary flash required. But it does not reduce the data itself. The data still exists, you still own it, and you still pay for it. The cost has simply moved from one category to another.
When an efficiency guarantee includes tiered data in its ratio, the claim is measuring something different from on-array data reduction. You can ask vendors a simple diagnostic question: “If I remove the tiering component from your efficiency calculation, what is the on-array reduction ratio for my data profile?” The answer to that question is what determines how much primary flash you actually need to buy.
The compound effect: What else gets included
Beyond tiering, some efficiency guarantees also incorporate:
- Space-efficient clones: Clones share physical blocks with the source volume, which can be valuable in development and test environments.
- Snapshots: Point-in-time snapshot copies that share blocks with the source volume reduce the storage overhead of maintaining recovery points.
- Thin Provisioning: Soft reservations for volume growth that show as “empty” even though they are “reserved”
All of which are useful capabilities. But neither one reduces the footprint of production data in the same way on-array deduplication and compression do.
Once dedupe, compression, tiering, clones, thin provisioning and snapshots are rolled into one ratio, the headline number can get much larger. That does not necessarily make the number wrong. It means the number is measuring a broader mix of effects, and using them interchangeably in a capacity planning model can lead to you running out of raw capacity before you expect to.
The math behind data reduction vs. data tiering
For a 100TB logical data set, the same environment can produce very different reported ratios depending on what gets counted.
| What’s Being Measured | Ratio | Physical Capacity Needed |
| Raw (no reduction) | 1:1 | 100TB |
| Inline dedupe + compression only | 4:1 | 25TB |
| Add tiering (60% cold data to S3) | Reported as ~8:1 | 10TB flash + 60TB object |
| Add clones + snapshots + thin provisioning | Reported as > ~10:1 | Varies |
That is why one vendor can claim >10:1 storage efficiency while another claims 4:1 and both can be describing the same underlying flash purchase. One number is more impressive. The other is more transparent.
The cleanest way to resolve the ambiguity is to ask for the efficiency calculation in the management console for the actual workload being evaluated.
What a clean guarantee looks like
Everpure’s 5:1 Right-Size Guarantee covers what happens on the primary storage array: inline deduplication, compression, and pattern removal. Nothing that gets tiered off-array. Nothing that depends on how many clones your development team creates. Nothing that requires a second bill from a cloud provider to make the math work.
It’s also contractual and binding. If our platform does not deliver 5:1 on-array reduction on the customer’s data, we deliver incremental capacity or issue a credit. The obligation is ours, not a conditional projection based on favorable workload assumptions. A non-contractual guarantee comes with assumptions, extra professional services costs and even software obligations all of which add cost to your overall solutions and fail to share risk.
The physical consequences of getting this right
If the distinction between on-array reduction and tiering sounds like a technical detail, here’s where it becomes a practical conversation.
Genuine on-array data reduction means fewer physical drives in the chassis. Fewer drives mean lower power draw, less heat, and less rack space consumed over the life of the platform. Every drive you do not have to buy is also a drive you do not have to power, cool, and maintain for the next seven to ten years.
Our DirectFlash® Modules achieve 3X–4X higher density than commodity SSDs in comparable environments and consume 39%–54% less power per TB. Combined with true on-array data reduction, that produces measurable differences at the infrastructure level:
- 61% less power consumption vs. comparable legacy systems
- 60% less heat generated—with direct implications for cooling infrastructure and cost
- 40% less rack space—which in a colo or constrained data center is real estate with a real dollar value
Tiering does not positively change any of those numbers. When cold data moves to object storage, the primary flash that remains in the chassis is still drawing power, generating heat, and occupying rack space. If it’s moving to hard disk based solutions the operational costs grow exponentially. Although the acquisition cost of HDD may be lower, the cost of ownership has not disappeared; it has simply shifted from capex to opex.
Genuine data reduction produces a smaller physical footprint. Tiering produces a different billing arrangement.
A capacity model that treats those two things as equivalent will produce the wrong answer, and it will produce it six months after the purchase closes, when changing the model is expensive.
The question that settles it
Before you accept any storage efficiency number in a storage evaluation, ask the vendor to show it on the actual data profile in the management console. Then ask them to break it apart:
- What portion comes from on-array dedupe and compression?
- What portion comes from tiering?
- What portion comes from clones and snapshots and thin provisioning?
- What are the assumptions and concessions tied to your guarantee? What happens if you fail to meet your promised efficiency?
Those numbers should be written down separately because the first one determines how much primary flash you actually need to buy. The others may still be real and valuable capabilities, but they belong in a different conversation about cold data strategy, development environments, and protection overhead. They do not belong in the denominator of primary storage sizing math.
A vendor that can show that breakdown clearly, with current data and without sending you to a footnote, is giving you a number you can actually plan around. A vendor that is truly sharing your risk is the one you should trust.
Inside Object Storage
Learn about benefits, use cases, and opportunities on when, where, and why to leverage an object storage architecture.






