Plenum bills what you hold: what reaches the bill is bytes the estate is actually holding, and the 54 GB of capacity that isn't holding any doesn't. The capacity is unchanged - what's changed is who carries the idle part of it.

Metered by the hour, not by the month: the figure above is a month of holding this much, and a volume that arrives halfway through the month is charged for half of it. Each window is reduced to its lowest reading, so compaction and rebalancing don't land on the bill.

You won't see a storage estimate for Plenum in the console: usage-based bytes aren't known when a cluster is sized, so what's quoted there is compute and storage arrives on the invoice. The storage figures here are this demo's model of what the meter would read.

Single region, and not on a Private Host Cluster: a host provisions the capacity its virtual clusters draw from, so the host itself isn't a Plenum cluster. Metered but not charged while it's in preview.

Tiered: 80% of the data stops keeping copies on disk and lives in object storage instead, so it bills as one copy rather than four. Nothing is deleted and no capacity comes back - the meter simply has less to count. 16 GB reaches the bill instead of 40 GB, which is 40% of keeping the whole estate on disk and takes the estimated cost above from 89% of the baseline to 88%.

The rate doesn't change: a byte in object storage is metered at what a copy on disk is metered at. Tiering is worth something because it removes bytes from the meter, not because it makes them cheaper.

The ratio is the point, not the size: the volume is the one you described on the front page, and every figure on the following pages follows it, including what a rebalance moves and what a dead node has to re-read.