Comparison
Tiering moves bytes. Compression removes some.
When a storage bill hurts, the suggestions arrive together: move it to Glacier, delete it, turn on dedup, zip it. They are not rivals. They answer different questions. Tiering asks how rarely you read. Deletion asks whether you need it. Dedup asks whether you stored it twice. Compression asks whether the copy you keep can be smaller and still come back the same. Pick the question your invoice is asking.
What does storage tiering actually save?
Tiering saves on the rate you pay to hold bytes you rarely read, if the colder class is cheaper for your region and you accept its retrieval rules. It does not reduce the number of bytes. Transitions can cost requests. Some classes bill a minimum duration. Read the current class page before you move a bucket.
Amazon S3, Google Cloud Storage, and Azure Blob Storage all offer classes for infrequent and archive access. AWS describes lifecycle transitions and Intelligent-Tiering on its cost-optimization pages. The savings they advertise are their claims about their classes, not a measurement of your data and not a qzip number. Follow the link and read the current conditions. A class that is cheap at rest can be expensive to leave, either in retrieval fees or in a minimum number of days.
Tiering is the right tool when the access pattern is the problem. Logs older than a month, backups you hope not to restore, and datasets between training runs do not need the hottest disk. It is the wrong tool when the object is downloaded all day. Moving a hot object to a cold class makes every read a retrieval. You will feel that on the next bill and in the next incident.
Lifecycle deletion is tiering's stricter sibling. Expiring an object removes the bytes and the future bill. It is the correct move for data past its policy. It is not available when the policy says keep it. Do not let a compression project delay a deletion you already decided. Delete first. Then the remaining estate is the one worth shrinking or tiering.
How is deduplication different from compression?
Dedup stores one copy of bytes that repeat across files. Compression stores one file in fewer bytes, even when nothing else matches it. Dedup wins when you saved the same object many times. Compression wins when a single object is redundant inside itself. Backup systems often do both. Neither one deletes a unique file you meant to keep.
A backup of ten virtual machines that share an operating system is a dedup problem. The identical blocks do not need to land ten times. A unique database dump with repetitive text is a compression problem. The blocks are not shared with another file. They are larger than they need to be on their own. A system can dedup and then compress the remaining chunks. That is a common backup design, and it is why a second compressor sometimes finds nothing: the product already did the work.
Dedup has a restore cost of its own. The unique data is scattered, and a full restore may reassemble a lot of chunks. Compression has a restore cost too: you need the decompressor and the CPU time. Count both in a design. A ratio that ignores the tool you must keep next to the data is incomplete. The text benchmark includes the decompressor in the total for that reason. Your backup format should be just as explicit.
Dedup across two clouds usually does not exist. Each vendor's backup store dedups inside itself. Copying that store to another provider sends the unique chunks, which is still a lot of bytes, and the destination will not know they were deduped. Compression of what you send still applies on that path. Dedup does not travel for free.
When is lossless compression the right spend?
Use it when you will keep the bytes, you need the same bytes back, and a sample shows the files shrink enough to matter at your rates. Skip it when the files are already dense, when you should delete them, or when a free path means size is not the meter. A benchmark on someone else's text does not decide.
Lossless is the constraint for backups, logs you might audit, datasets, and masters. You do not get to return a smaller, different file. Gzip, zstd, and other general-purpose tools are legitimate ways to do this yourself. We are not going to invent a ranking against them. If you already zstd a dataset and it is small enough, you may be done. If you have a pile that those tools barely move and the bill is still wrong, that is a sample worth sending us. We will measure it. We will not claim a win we did not score.
The spend is worth it when your own arithmetic says so. Type your storage rate and your egress rate into the calculator. Type a ratio you are willing to assume, not 10.7 and not a number you saw on our homepage. If the yearly difference is noise, do not start a project. If it is a real line, prove the ratio on a sample before you multiply it by the estate. A wrong ratio, confidently multiplied, is how storage business cases embarrass people.
Put compression before the copies fan out. Before replication, before the long retention, before the customer download, when those paths are billed. After the fan-out, you can still shrink the next copy, but you cannot unpay the last one. Tiering can still follow. A smaller object in a colder class is a perfectly reasonable pair. They were never opposites.
How do I choose for one bucket?
If you do not need the object, expire it. If you need it rarely, tier it and respect the minimum duration. If many objects are the same, dedup. If a sample shrinks and you will keep it, compress it. One bucket can need all four. Write the choice next to the prefix so the person does not redo the argument.
A practical review takes an afternoon with inventory, not a new platform. Group prefixes by why they exist: logs, backups, datasets, media, build artifacts. For each, write keep or delete, hot or cold, unique or repeated, dense or maybe not. The maybe-not row is the sample list. Everything else is a lifecycle rule or a dedup setting you already own.
Revisit after a month because the first rule is often wrong. A prefix you thought was cold gets downloaded by a job you forgot. A prefix you compressed was already zipped inside. A prefix you kept for compliance had a shorter contract than the runbook claimed. The bill is the feedback. Our job, if you want it, is the sample on the maybe-not row, measured and restorable.
Bring the provider page into the review with the date in the notes. Class rules change. A decision memo that quotes a rate from memory will be wrong in a quiet, expensive way. This site links the pages and stops there on purpose. The dollars are yours to type.
What each move changes.
| Move | What it reduces | What it does not | Tradeoff |
|---|---|---|---|
| Expire | Bytes you stop keeping | Anything the policy requires | You cannot restore what you deleted |
| Tier | The rate on bytes you rarely read | The size of the object | Retrieval rules and minimum duration |
| Dedup | Repeated blocks across files | A unique file's internal redundancy | Restore reassembles chunks |
| Lossless compression | Bytes inside a file you keep | Request fees and files that are already dense | You must be able to restore |
Questions.
Is compression better than Glacier?
They are not substitutes. Glacier-class storage changes the rate and the rules for bytes you rarely read. Compression changes how many bytes you store. Use a cold class for long-lived, rarely read copies. Compress if a sample shows those copies can be smaller and still restore.
Should I turn off zstd and use qzip?
Not on the strength of this page. Zstd and gzip are fine tools. If they already shrink your data enough, keep them. If the bill is still wrong and the files are still large, send a sample. We will measure it against the original bytes. We do not publish a ranking against other compressors.
Can I tier and compress the same object?
Yes. Shrink it first if you want the cold copy to be the small one, then transition the smaller object. Remember that a transition can be a request charge and that some classes have a minimum duration. Read the lifecycle docs before you automate both.
Provider docs, not our price list.
Links checked Oct 21, 2026. Rates and rules on those pages can change.
Keep reading.
Send us a sample.
We will measure it on your files. We will not quote a savings number we have not measured. Write hello@qzip.ai or join the waitlist.