Glossary
Petabyte Storage
Petabyte storage means storing a thousand terabytes or more in a single system. It is a threshold rather than a product category: at this size, the methods that work for a few hundred terabytes stop working, and the system has to be built differently.
What changes is not the capacity number. It is failure rates, protection overhead and repair time.
How big a petabyte actually is
A petabyte is 1,000 terabytes, or a million gigabytes. In hardware terms, at today's largest generally available drives of about 32 TB, that is roughly 32 drives — one rack shelf, not a data hall.
Your monitoring will not report 1 PB, though. It will report about 0.89 PB, or 909 TiB. Nothing has gone missing. Drive manufacturers count in decimal units where a terabyte is a trillion bytes; most operating systems count in binary units where a terabyte is 1,099,511,627,776 bytes. The same capacity, described two ways, with an 11% gap between them that grows as capacity grows.
Plan purchases in the units the vendor quotes and monitor in the units your tools report, and be explicit about which one a capacity figure refers to.
Why drive failure changes the design
Hard drives fail at somewhere around 1.4% a year across large fleets. That number is stable. What changes with capacity is how many drives you own.
| Capacity | Drives (at 32 TB) | Expected failures |
|---|---|---|
| 100 TB | ~3 | One every 20 years or so |
| 1 PB | ~32 | One every couple of years |
| 10 PB | ~320 | One every few weeks |
| 100 PB | ~3,200 | Roughly one a day |
At the top of that table, a failed drive cannot be an incident that pages someone. The system has to keep serving data through failures, repair itself without intervention, and report what happened afterwards. That single requirement drives most of what follows.
Keeping three copies stops being affordable
The traditional answer to drive failure is to hold multiple copies. Three copies is simple, fast to read from, survives two simultaneous losses, and repairs by straight copying. It also means buying three petabytes of hardware to store one.
Erasure coding splits each object into k data fragments and computes m parity fragments, spread across different drives, servers or racks. Any k of the k+m fragments reconstruct the original, so the system survives m simultaneous failures at far lower overhead.
| Protection scheme | Raw capacity for 1 PB usable | Overhead | Failures survived |
|---|---|---|---|
| Three replicas | 3 PB | 200% | 2 |
| Erasure coding 6+3 | 1.5 PB | 50% | 3 |
| Erasure coding 12+4 | 1.33 PB | 33% | 4 |
| Erasure coding 17+3 | 1.18 PB | 18% | 3 |
At 100 TB the difference between these schemes is a rounding error on the purchase order. At 50 PB it is tens of millions in hardware, plus the racks, power and cooling that go with it.
Erasure coding is not free. Writes require computing parity and touching more devices, so small-object and latency-sensitive workloads often keep replication while bulk data uses erasure coding. Systems that let you set this per class of data rather than once for the whole cluster avoid paying replication overhead on archives.
Rebuild time is the number that matters
When a drive fails, the system reconstructs what was on it. Until that finishes, the affected data is running with less redundancy than the design promises — and a second failure during that window is what actually causes data loss.
Two things make rebuilds slower as capacity grows. Drives get bigger, so there is more to reconstruct. And erasure coding means reconstructing a fragment requires reading k other fragments, so repair generates several times more read traffic than the amount of data being restored.
The difference between systems is where that work happens. In a traditional RAID array, one replacement drive is the bottleneck: everything is written to it, at that drive's speed. Rebuilding 32 TB onto a single drive at a sustained 150 MB/s takes about two and a half days, and that is with no production load competing for the same spindles.
Distributed systems spread the reconstruction across every remaining drive and server, so hundreds of devices each do a small share. The same repair completes in hours. When evaluating platforms at this scale, rebuild time under load is a more useful question than peak throughput.
Why the architecture changes too
Scaling up — putting bigger drives in a bigger controller — runs into a ceiling. One chassis holds a finite number of drives, one controller pair has finite CPU and memory, and eventually you buy a second array and start managing capacity by hand across islands.
Scale-out systems add capacity by adding nodes, each contributing drives, CPU, memory and network to a single pool. Capacity and performance grow together, and the system stays one thing to manage.
The metadata layer is usually what breaks first. Traditional file systems maintain a directory tree, and a tree with billions of entries becomes a contention point long before the drives are full. Object storage flattens this into a namespace of objects addressed by key, with metadata distributed rather than centralised — which is why most petabyte-scale systems built in the last decade are object stores with an S3 interface rather than file systems.
What the cost is actually made of
Drives are the visible line item and rarely the largest one. Over a five-year life, the recurring costs are:
- Power and cooling. Every drive draws power continuously and every watt drawn becomes heat that has to be removed. This is a monthly bill for the life of the system.
- Rack space. Charged per rack unit, and driven by drive density — how many terabytes you fit per U determines how much floor space a petabyte occupies.
- Protection overhead. The difference between 200% and 33% is not an accounting detail; it is the number of racks you have to fill and power.
- Refresh. Drives are replaced on a cycle, typically five years. At petabyte scale that migration is continuous background work rather than a project.
- People. The main reason to care about self-healing and single-namespace management is that they determine whether capacity growth requires headcount growth.
For public cloud storage the same drivers exist but appear as monthly charges, with egress fees and retrieval charges on archive tiers as the two that most often surprise people at this scale.
Who ends up here
Petabyte scale is normal in medical imaging, where a hospital group accumulates tens of petabytes of scans it must retain for decades; in genomics, where a single sequencing run produces hundreds of gigabytes; in media, where uncompressed 4K and 8K masters are measured in terabytes per hour; in video surveillance, where retention policy multiplied by camera count arrives at petabytes quickly; and in AI, where training corpora and model checkpoints grow with every run.
The common thread is that the data is retained rather than deleted, so capacity only moves in one direction — which is why the cost per usable petabyte and the ability to grow without redesign matter more than headline performance.
How Scality builds at this scale
Scality RING is a scale-out object store designed for this range. Protection is set by policy per class of data, so replication can be used where latency matters and erasure coding where capacity does — rather than choosing once for the whole system. When a drive fails, RING rewrites the affected data across the remaining drives in that server, and rebuilds only the data that was actually written rather than the drive’s full capacity.
Scality ARTESCA covers the smaller end of the range, validated from 20 TB to 8.5 PB, with the same S3 interface.
For a sense of the upper bound: Scality currently has around six exabytes under management across its customer base, including a single RING holding 300 billion objects.