Ceph capacity calculator
What can your Ceph cluster really store? Usable capacity for replicated and erasure-coded pools, minus the parts most calculators skip: the full ratio that stops writes long before disks are physically full, and the headroom the cluster needs to heal itself when a host dies.
Usable capacity
All schemes on this topology
| Scheme | Usable | Efficiency | Host failures | Min hosts |
|---|
How it's calculated
Raw capacity is hosts × OSDs × OSD size, in decimal TB. Replication divides it by the replica count; erasure coding keeps k/(k+m) of it. With the default failure domain of host, each replica or EC chunk lands on a different host, so a scheme needs at least size (replication) or k+m (EC) hosts to place data at all, and it tolerates size−1 or m simultaneous host failures.
Then come the margins that separate paper capacity from real capacity. Ceph raises nearfull warnings at 85% by default and stops writes at the full ratio, so plan against your chosen ratio, not 100%. The self-heal option answers a question every operator eventually faces at 3 a.m.: if a host dies, can the survivors absorb its data and return to full redundancy? Reserving that headroom multiplies capacity by (hosts−1)/hosts, and it also needs one host more than the scheme minimum to have somewhere to rebuild. Skip it only if you accept running degraded until hardware is replaced.
Deliberately out of scope: BlueStore metadata and DB/WAL overhead (a few percent), uneven OSD utilization that wastes space before the fullest OSD hits the ratio (the balancer helps), performance differences between replication and EC (EC saves space and costs IOPS and latency, especially on small writes), and CephFS or RGW overhead on top of RADOS. Wide EC profiles like 8+3 look great on efficiency and need eleven healthy hosts before they store a single object; most small clusters are happier with 3x replication or 4+2 than the spreadsheet suggests.