Red Hat Ceph Storage, priced by raw capacity.

Red Hat Ceph Storage prices on the raw capacity of the Ceph cluster, measured in terabytes of physical storage that the cluster manages. The metric is on raw capacity rather than usable capacity, which matters because Ceph's replication, erasure coding, and overhead reduce the usable footprint substantially below the raw footprint. A cluster with one hundred terabytes of raw capacity and a three way replication policy presents roughly thirty three terabytes of usable capacity to consumers1. The licensing line reads against the hundred terabytes regardless.

The convention rewards storage efficiency choices that reduce the raw footprint for a given usable footprint. Erasure coding policies that produce closer to the underlying capacity reduce the licensing line per usable terabyte. Replication policies that consume more raw capacity per usable terabyte increase the licensing line per usable terabyte. The buyer side reading at the renewal table benchmarks the raw to usable ratio against the cluster's actual consumption pattern and the resilience requirement, and surfaces whether the ratio reflects a deliberate operational choice or an accidental over replication.

The raw capacity metric also implies that cluster growth surfaces in the licensing line as raw terabytes added, not as objects, files, or blocks stored. A storage workload that grows in object count but not in capacity does not change the licensing line. A storage workload that grows in capacity changes the line at the next renewal or audit reading. Capacity expansion is the licensing event; data ingest is not.

Red Hat Ceph Storage is sold in two packaging variants. The standalone Red Hat Ceph Storage subscription provides Ceph as a storage platform on dedicated infrastructure, typically licensed to a Ceph cluster that serves block, object, or file storage to consumers across the broader estate. OpenShift Data Foundation, packaged as a Red Hat product line, provides Ceph as the persistent storage engine on OpenShift clusters, licensed per worker node on the OpenShift cluster rather than per terabyte of raw capacity2.

The two variants carry the same engine. The Ceph code base, the RBD block device, the RGW object gateway, and the CephFS file system are common across both. The commercial reading at the renewal table is what differs. Standalone Ceph reads on raw capacity in terabytes. ODF reads on OpenShift worker nodes, with the implicit assumption that the Ceph storage scales with the cluster footprint. A buyer who runs OpenShift with ODF for persistent volumes on the cluster and standalone Ceph for an adjacent object storage estate carries two Red Hat lines on the same Ceph engine.

The reading at the renewal table is whether the two lines can be consolidated or whether the consumption pattern warrants two separate Ceph deployments. A workload that uses Ceph object storage at scale through an external application stack often warrants standalone Ceph on dedicated hardware, because the workload's capacity and performance profile would not fit cleanly inside the ODF cluster scope. A workload that needs persistent volumes for containers on the OpenShift cluster fits ODF cleanly. A workload that does both may sit on either depending on the dominant consumption pattern.

Red Hat Ceph Storage subscriptions carry a cluster minimum sized on raw capacity. The exact threshold varies by SKU and changes across releases, but the structural reading is that a Ceph cluster below the minimum still carries the minimum on the line. The buyer who deploys a small Ceph cluster for an isolated workload pays for the minimum rather than for the actual cluster size if the cluster sits below the threshold.

The minimum implies that small Ceph deployments are commercially inefficient on the standalone subscription. A buyer with a thirty terabyte raw capacity Ceph cluster and a minimum at fifty terabytes pays for fifty. The right response is rarely to grow the cluster artificially. The right response is to either consolidate small Ceph deployments onto a single larger cluster, move the workload to a different storage backend that prices more cleanly at small scale, or carry the cluster on the alternative ODF line if the workload sits on or adjacent to OpenShift.

Cluster growth above the minimum scales linearly on the per terabyte rate, with discount tiers at larger scale. The discount tiers favour consolidation onto fewer larger Ceph clusters over the proliferation of small Ceph clusters across the estate. A buyer with five small Ceph clusters across business units typically pays more in aggregate than the same workload consolidated onto a single larger cluster, even after operational overhead is netted out.

Red Hat Ceph Storage subscriptions carry a support tier overlay on top of the per terabyte capacity line. The support tiers follow the standard Red Hat structure with response times, severity escalation, and 24x7 coverage scaling across the tiers. The premium tier prices materially above the standard tier, and the standard tier prices above the self support tier where the latter is available.

The reading at the renewal table on the support tier is operational rather than commercial. The premium tier is warranted where the Ceph cluster sits in a critical path with a defined recovery time objective, the operational team has 24x7 production responsibility, and the cluster's incident history justifies the higher tier. The standard tier covers the more common case of business hours operational responsibility with on call coverage from the buyer's own team. A buyer who carries the premium tier across the entire Ceph estate without a tier by tier reading typically pays a premium that does not match the cluster's actual operational profile.

The buyer side discipline reads the support tier by cluster rather than by estate. A production Ceph cluster serving a critical workload carries the tier that the workload's recovery time requires. A development or staging Ceph cluster carries a lower tier. The aggregate support tier line across the estate sums the per cluster readings, and is often materially below the line that a uniform premium tier across the estate produces.

The renewal table on Red Hat Ceph Storage reads three lines: the raw capacity line on the per terabyte rate, the support tier overlay, and any adjacent ODF line that consumes Ceph through the OpenShift cluster footprint. The reading separates the three, sizes each against actual consumption, and surfaces whether the lines can be consolidated.

The capacity reading benchmarks the raw to usable ratio against the resilience requirement and the consumption pattern. The support tier reading benchmarks the tier against the cluster's operational profile. The ODF interaction reading benchmarks whether the Ceph consumption belongs on a standalone line or inside the OpenShift cluster scope. A subscription assessment across the storage estate produces the line by line reconciliation that the renewal table reads against.

The buyer side posture at the audit notice on the Ceph line reads the cluster raw capacity against the subscription record, with the cluster as the unit of audit. The audit posture is comparatively narrow because the metric is a single number per cluster. The defensive discipline is to maintain a current raw capacity reading per cluster on a quarterly cadence, so the audit notice arrives against a record the buyer can produce. An audit defense on a Ceph cluster reads the recorded raw capacity against the subscription record at the time the cluster was last sized.

For the broader storage practice context, see the storage and virtualization practice hub. For the OpenShift Data Foundation reading, see ODF pricing. For the engagement protocol, see contact.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.