Ratio and space savings are the same fact, stated differently
The compression ratio is the original size divided by the stored size, quoted as n:1. Space savings is the fraction of the original you no longer store, quoted as a percentage. Both describe one measurement, and converting between them is a single expression: savings = 1 − 1/ratio.
The reason to keep both in mind is that they scale differently, and that difference drives bad purchasing decisions. Moving from 2:1 to 4:1 sounds like doubling the benefit; it moves savings from 50% to 75%, so you halve the remaining data. Moving from 10:1 to 20:1 sounds equally impressive and moves savings from 90% to 95% — five points. Every doubling of the ratio halves what is left, so the absolute benefit of each doubling halves too. Beyond about 10:1, further ratio improvements have very little effect on how much hardware you buy.
Storage vendors quote the ratio because it is unbounded and therefore sounds larger. Backup and file-system reports often quote savings because it is bounded and easier to reason about. Neither is dishonest; they simply flatter different arguments, and being able to move between them in your head is the defence.
Note also what the words cover. Compression removes redundancy inside a stream. Deduplication removes whole blocks that already exist elsewhere. Storage vendors combine both, plus thin provisioning and sometimes zero-block elimination, into a single data reduction ratio, and the arithmetic on this page applies unchanged to that combined figure — as long as you know which components are included in the number you were given.
The three expressions you need
Ratio = original ÷ compressed. 500 GB reduced to 125 GB is 500 ÷ 125 = 4, quoted as 4:1. The units cancel, so it does not matter whether you work in bytes, gigabytes or tebibytes, provided both figures use the same one.
Space savings = (1 − compressed ÷ original) × 100. The same example gives (1 − 125/500) × 100 = 75%. Equivalently, and more usefully when you have been quoted a ratio rather than sizes, savings = (1 − 1/ratio) × 100 = (1 − 0.25) × 100 = 75%.
Effective capacity = physical capacity × ratio. This is how an array's marketing capacity is derived: 10 TB of physical flash at an assumed 4:1 reduction is advertised as 40 TB effective. The multiplication is correct and the assumption is the risk — the ratio is a property of your data, not of the array, and a workload of encrypted volumes or media files will reduce at close to 1:1 no matter what hardware it sits on.
Two consequences follow directly from the shape of these expressions. First, savings can be negative: if the stored size is larger than the original, the ratio falls below 1 and savings goes below zero. That is not an error — compressors add a header and cannot shrink data that is already close to random, so encrypted and previously compressed files often come out very slightly larger. Second, savings approaches but never reaches 100%, because the compressed size cannot reach zero. A quoted ratio of infinity would mean storing nothing at all.
When comparing two compressors, compare on the same data set. A ratio measured on log files says nothing about the ratio on virtual machine images, and a ratio measured across fifty near-identical virtual machines is mostly deduplication rather than compression — it will not reproduce on a set of fifty different ones.
Worked example: sizing an array from a quoted ratio
A team has 500 GB of logical data, measures the stored size after compression at 125 GB, and is deciding how much physical capacity to buy for a 10 TB logical requirement.
- Compute the ratio. 500 ÷ 125 = 4, so the reduction is 4:1.
- Convert to savings. 1 − 125/500 = 0.75, so 75% space savings. Check it the other way: 1 − 1/4 = 0.75. The two routes agree, which is the point of the identity.
- Find the space saved. 500 − 125 = 375 GB, and 375 ÷ 500 = 75%, consistent with step 2.
- Express the result as a share of the original. 125 ÷ 500 = 25%, which is 100% − 75%. Savings and remaining share always sum to 100%.
- Forecast the array. A 10 TB logical requirement at 4:1 needs 10,000 ÷ 4 = 2,500 GB of physical capacity, or 2.5 TB. Read the other way, 10 TB of physical capacity would hold 10,000 × 4 = 40,000 GB of logical data.
- Test the assumption. If the real ratio turns out to be 2:1 rather than 4:1, the same 10 TB logical requirement needs 5,000 GB — exactly twice as much. Halving the ratio doubles the physical capacity needed, so the purchasing risk is entirely in the ratio estimate, not in the arithmetic.
That last step is the reason to measure rather than accept a datasheet figure. Run a representative sample of your own data through the reduction path and derive the ratio from what actually lands on disk.
What a given ratio tells you
Around 1:1 means the data is effectively incompressible. Media files, encrypted volumes and existing archives are already dense, and running a general-purpose compressor over them costs CPU and returns nothing. Modern arrays detect this and stop trying, which is why an all-media workload shows a reduction ratio barely above 1 no matter what the array is capable of.
Between 2:1 and 4:1 is the ordinary range for mixed business data — documents, databases, application binaries and the operating systems around them. It is what a general-purpose array on a general-purpose workload typically reports, and it is the range most capacity planning should assume in the absence of a measurement.
Above 10:1 almost always indicates deduplication across many similar objects rather than compression within one. Fifty virtual desktops built from one image share nearly all their blocks; a backup repository holding thirty daily copies of the same file server does too. These ratios are real and useful, and they are entirely a property of the redundancy between objects, so they collapse the moment the data set becomes heterogeneous.
Below 1:1 is expansion. It is expected on high-entropy input and is nothing to fix, though it is a signal that whatever is spending CPU on compression here should be turned off for that data type.
One practical warning about combining numbers: reduction ratios do not multiply cleanly across stages. If compression achieves 2:1 and deduplication then achieves 3:1 on what remains, the combined ratio is 6:1 only if the two act on independent redundancy, which they rarely do — deduplication removes blocks that compression would also have found. Measure the end-to-end ratio rather than multiplying stage figures together.
Compression ratio and space savings side by side
| Ratio | Space savings | Stored as % of original | Physical needed for 10 TB logical |
|---|---|---|---|
| 1:1 | 0% | 100% | 10,000 GB |
| 1.25:1 | 20% | 80% | 8,000 GB |
| 1.5:1 | 33.33% | 66.67% | 6,667 GB |
| 2:1 | 50% | 50% | 5,000 GB |
| 2.5:1 | 60% | 40% | 4,000 GB |
| 3:1 | 66.67% | 33.33% | 3,333 GB |
| 4:1 | 75% | 25% | 2,500 GB |
| 5:1 | 80% | 20% | 2,000 GB |
| 8:1 | 87.5% | 12.5% | 1,250 GB |
| 10:1 | 90% | 10% | 1,000 GB |
| 20:1 | 95% | 5% | 500 GB |
| 100:1 | 99% | 1% | 100 GB |
The physical column is 10,000 GB divided by the ratio. Going from 4:1 to 8:1 saves 1,250 GB of hardware; going from 20:1 to 100:1 saves 400 GB.
Mistakes that make a ratio meaningless
- Comparing ratios measured on different data. A compressor's ratio is a joint property of the algorithm and the input. Benchmarks are only comparable on the same corpus.
- Accepting a datasheet ratio for capacity planning. Effective capacity claims assume a reduction ratio. If your data reduces at half the assumed rate, you need twice the hardware.
- Multiplying stage ratios together. Compression and deduplication compete for the same redundancy, so a 2:1 and a 3:1 stage rarely produce 6:1 end to end.
- Compressing encrypted or already-compressed data. It costs CPU, returns nothing, and occasionally expands the data slightly because of the container header.
- Confusing logical and physical figures on an array. Free space reported at the logical layer assumes the ratio continues; a change of workload can consume physical capacity far faster than the logical figure suggests.
- Ignoring what compression costs elsewhere. Higher ratios generally mean more CPU on write and, for some algorithms, slower reads. On a latency-sensitive database that trade can be the wrong one even when the space saving is real.
- Assuming the ratio holds as the data set grows. Deduplication ratios in particular depend on repetition across objects, and they fall as the set becomes more varied.
Where reduction ratios are used
Three places, each with its own conventions. On primary storage, arrays apply inline compression and deduplication and report a data reduction ratio that may also include thin provisioning and zero-block elimination; ask which components are counted before comparing two vendors. On backup targets, deduplication across many similar restore points dominates, and the headline ratios are much higher — they are also the reason backup appliance capacity is quoted in logical terms. In file formats and transfer, compression is a per-object property and the ratio determines both storage and transmission cost.
That last case links directly to time. Compressing before transfer moves less data, so it shortens a copy in proportion to the ratio — provided compression happens at the source rather than at the destination. The same distinction governs whether reduction helps a backup window at all, which the backup window calculator makes explicit, and it decides whether a data transfer time estimate should use the logical or the reduced size.
When you convert an effective capacity claim into hardware, watch the units as well as the ratio. Drives are sold in decimal terabytes while operating systems report binary tebibytes, so a 10 TB array shows about 9.09 TiB before any reduction arithmetic starts — the TB to TiB storage capacity calculator covers that gap. And if the array is protected, RAID overhead comes off before compression is applied to what remains, which the RAID capacity calculator works out.
Finally, the honest way to plan is to measure. Take a representative slice of the actual data, push it through the actual reduction path, and record what lands on disk. Every figure on this page is arithmetic; only that measurement is evidence.