Object storage sizing starts with the amount of data you need to retain, then accounts for the space required to protect it and keep the system operating. Raw capacity is the installed storage available before those deductions. Usable capacity is what remains after protection and system overhead, although suppliers do not always include the same deductions in that figure.
That difference matters when a hardware quote arrives. A system advertised with a petabyte of raw storage cannot necessarily hold a petabyte of your objects. Even a petabyte of usable capacity may leave too little room for growth, maintenance or recovery if you plan to fill it completely.
A useful sizing model makes each assumption visible. Start with retained data, apply the selected protection policy, account for platform overhead and preserve operating headroom. Then check that the resulting hardware can support the workload and the failures it must tolerate.
What is the difference between raw and usable capacity?
Raw capacity is the sum of the storage devices included in the capacity pool. For example, 60 drives rated at 20 TB provide 1,200 TB of nominal raw capacity. Boot drives, dedicated metadata devices and other separate resources should be identified rather than silently included in that total.
Usable capacity describes the space available for stored objects after specified deductions. Those deductions may include replicated copies, erasure-coding parity, formatting, metadata and reserved space. The important word is “specified”: a quote that subtracts parity alone is different from one that also accounts for system overhead and operational reserves.
For planning, keep three figures separate:
| Capacity measure | What it tells you |
|---|---|
| Raw capacity | How much physical storage the proposed pool contains |
| Usable capacity | How much object data fits after the stated protection and system deductions |
| Planned occupancy | How much of that usable space you intend to fill before expanding |
Planned occupancy is a planning term here, not a standardized product metric. It helps separate the space a system exposes from the amount you can commit to applications under your operating policy. Ask suppliers to explain exactly where their quoted capacity sits in this sequence.
Keep TB and TiB consistent
A terabyte and a tebibyte describe different quantities. One TB is one trillion bytes; one TiB is approximately 1.10 trillion bytes. A drive advertised as 20 TB therefore contains approximately 18.2 TiB before protection or formatting.
That numerical difference is a unit conversion, not lost capacity. Use the same units for the workload inventory, hardware quote and monitoring dashboard before calculating any overhead. The worked example below uses decimal TB throughout.
Start with retained data, not today’s visible files
The first input should be the data expected to remain on the platform at the end of the planning period. That includes current objects, expected growth and historical data that retention policies require you to keep. A directory listing or application dashboard may show only part of that total.
For an archive, estimate new ingest alongside the data expected to expire. For a backup repository, use the backup application’s projected repository footprint under the intended backup schedule and retention policy. Multiplying the size of the production environment by the number of restore points is rarely a useful substitute for that estimate.
A practical inventory records the source of each forecast. Separate measured occupancy from expected growth and policy-driven retention. This makes it possible to revisit an assumption without rebuilding the entire sizing exercise.
Include versions and deletion timing
Versioning can keep older object contents after applications overwrite them. In Amazon S3, deleting an object in a versioned bucket normally adds a delete marker, while previous versions remain unless explicitly removed or expired through an appropriate lifecycle rule. A current-object listing can therefore understate the retained footprint.
For sizing, request current and noncurrent object totals separately. Confirm when eligible data is actually reclaimed, rather than assuming that a logical delete immediately releases physical capacity. Apply the target platform’s documented behavior when estimating reclamation delays.
Immutable retention also changes the forecast because protected data may need to remain longer than the application actively uses it. Include the overlap between incoming data and copies that cannot yet expire. Treat this as retained workload data before applying storage protection overhead.
Give data reduction credit only once
If a backup application already compresses or deduplicates data before writing it, use its resulting repository estimate as the starting point. Do not apply the same reduction again at the storage layer. Any additional savings should come from measurements of representative data on the proposed configuration.
Record both the measured ratio and the data sample behind it. A favorable result from one dataset should not automatically apply to every workload. Keep an unreduced scenario available so the capacity decision does not depend on an unverified assumption.
How protection changes the capacity requirement
Object storage consumes additional space to maintain data through hardware failures. Replication stores complete copies; erasure coding stores data fragments plus recovery information. The selected policy determines the first major adjustment between retained data and raw capacity.
With three-copy replication, every 100 TB of object data requires approximately 300 TB before other overhead. An illustrative 8+4 erasure-coding scheme uses eight data fragments and four parity fragments, requiring approximately 150 TB for the same payload.
| Illustrative protection policy | Raw space per 100 TB of object data | Payload share of raw space |
|---|---|---|
| Two complete copies | 200 TB | 50% |
| Three complete copies | 300 TB | 33.3% |
| Erasure coding, 8+4 | 150 TB | 66.7% |
| Erasure coding, 12+4 | 133.3 TB | 75% |
These are protection-only calculations, not finished system capacities or equivalent resilience guarantees. Fragment placement, failure domains and the implementation determine which hardware failures a configuration can tolerate.
For erasure coding, the protection multiplier is total fragments divided by data fragments. In an 8+4 example, that is 12 divided by 8, or 1.5. Fifty percent overhead relative to the payload means the payload occupies two-thirds of raw space, not half.
A single protection ratio may not describe the whole system
Scality RING can use replication for small files and erasure coding for larger files, with a tunable size threshold. Its architecture also supports different parity levels and deployment topologies. As a result, a RING estimate should reflect the actual object-size distribution and protection configuration.
Consider an illustrative workload with 90 TB under an 8+4 policy and 10 TB under three-copy replication. The protected footprint is 135 TB plus 30 TB, or 165 TB. Applying the 1.5 multiplier to the entire workload would predict only 150 TB.
Weight the calculation by data volume, not simply the percentage of objects. An object-size histogram should show both how many objects fall into each range and how many bytes those objects represent. This gives the sizing team a defensible basis for estimating a mixed protection footprint.
A worked object storage sizing example
Suppose an organization is planning an object storage deployment for the next year. It currently holds 300 TB of object data, expects 120 TB of additional retained data and projects another 60 TB in historical versions. The forecast is therefore 480 TB of retained object data.
For this example, assume all payload uses 8+4 erasure coding and the operating plan limits occupancy to 80% of usable capacity. The utilization limit is an illustrative planning choice, not a universal requirement or a Scality recommendation. Platform overhead and hardware layout still need separate validation.
| Step | Calculation | Result |
|---|---|---|
| Forecast retained data | 300 TB current + 120 TB growth + 60 TB versions | 480 TB |
| Provide operating headroom | 480 TB ÷ 0.80 | 600 TB usable |
| Apply protection | 600 TB × 1.5 | 900 TB raw |
The result is 900 TB of raw capacity before platform overhead and hardware rounding. It is a preliminary capacity requirement, not a purchase-ready configuration.
The headroom step leaves 120 TB of the 600 TB usable pool unoccupied. Simply adding 20% to 480 TB would produce 576 TB, which would already be more than 80% full. Dividing by the target utilization preserves the intended free-space percentage.
The vendor must then reconcile the preliminary requirement with metadata, system reservations, protection layout and supported hardware increments. If any reserve is already included in the quoted usable figure, identify it before adding another allowance. Otherwise, the estimate can become inflated through double counting.
Why free space needs an operational purpose
Operating headroom gives the team time and space to respond while the platform continues accepting data. Instead of choosing a percentage without explanation, specify what the reserve must support. That might include a burst of ingest, delayed expiration, maintenance or recovery after a defined failure.
An 80% cluster average alone does not establish that the platform has enough recovery space. Ask how utilization varies across nodes and protection groups, and what happens when a node becomes unavailable. The sizing review should distinguish continued access to existing data from the ability to restore the intended protection level.
Growth headroom also needs a time basis. A reserve that covers several months of normal ingest might cover only days during a migration. Translate the remaining capacity into time under the relevant growth scenario, then compare it with procurement and expansion lead times.
Account for metadata, performance and additional sites
Object count belongs in the sizing request alongside total bytes. A workload containing many small objects can have different metadata and request-processing requirements from a workload with the same capacity in large objects. Ask for the proposed metadata resources and their growth assumptions explicitly.
Capacity and performance should then be validated together. The proposed configuration must support the expected ingest, reads and concurrent requests while carrying the intended data volume. Where recovery performance matters, request testing that includes background recovery work rather than relying only on healthy-system throughput.
Additional sites require their own capacity model. If two independent sites each retain the full dataset with local protection, each site needs room for its retained copy. A geo-distributed protection scheme has different arithmetic, so establish the topology before multiplying a single-site estimate.
Keep retained bytes and local protection separate in the worksheet. This avoids both counting a remote copy twice and omitting the protection applied to that copy. Also identify whether the sites have matching retention policies or different capacity needs.
What to require in an object storage quote
A useful quote lets the infrastructure team trace the final hardware requirement back to the workload. Request the raw total, protection configuration, usable total, operating reserve and retained-data forecast together. Any compression or deduplication assumption should be labeled and supported.
Ask the supplier to answer five questions:
- What deductions are included in the quoted usable capacity?
- What object-size distribution and protection policies were used?
- How much retained data can we hold at the agreed operating limit?
- What failure and recovery conditions does the configuration support?
- When must we order the next expansion, and how much capacity does that expansion add?
Compare proposals using the same units, retention horizon and resilience requirements. Price per raw terabyte can favor a design that needs more hardware to hold the workload. Price per usable terabyte is also incomplete when proposals use different definitions of usable.
For a Scality RING assessment, provide the retained-data forecast, object-size distribution, expected request load and site topology together. Those inputs allow capacity and protection choices to be evaluated against the deployment you actually intend to run.
The purchasing requirement should state how much retained object data the system must support, under which protection policy and through which planning date. Raw capacity is the hardware needed to meet that requirement. Keeping those two statements connected makes the estimate reviewable and the next expansion easier to anticipate.