OpenShift Data Foundation, priced by worker node.

OpenShift Data Foundation is Red Hat's persistent storage product for OpenShift, built on Ceph, packaged as an OpenShift operator, and licensed as a Red Hat product line in its own right. ODF provides block, file, and object storage to applications running on the OpenShift cluster, with the storage running on the same worker nodes that run the application workloads, on dedicated storage worker nodes, or on external storage backends through the Ceph driver1.

The product is sold per worker node on the OpenShift cluster that consumes it, with a per node subscription rate that scales linearly with the cluster footprint. The metric is the worker node count rather than the worker core count, which differs from the broader OpenShift Container Platform convention. A buyer who reads ODF against worker cores misreads the line; the ODF line is per node, with the per node rate calibrated against an expected average node size in the field team's pricing model.

The product is also sold inside the OpenShift Plus bundle as one of the bundle's component lines. A buyer who purchases OpenShift Plus on a cluster carries ODF as one of the bundle components on that cluster, regardless of whether the cluster's workloads consume ODF in production. The bundle scope and the ODF scope are not separable inside the bundle line, which is part of what makes the bundle math complicated when the cluster does not consume ODF2.

ODF carries two tier overlays in the 2026 product structure. The Essentials tier covers the core ODF capability: block, file, and object storage on the cluster, with the standard Ceph engine underneath. The Advanced tier overlays additional capability, including multi cluster Ceph topologies, object bucket replication across clusters, regional disaster recovery patterns, and certain advanced data services. The Advanced tier prices materially above the Essentials tier on the per node line.

The reading at the renewal table on the tier is operational rather than commercial. The Advanced tier is warranted where the deployment consumes the Advanced features in production, typically in multi cluster topologies or regulated workloads with cross region disaster recovery requirements. The Essentials tier covers the more common case of single cluster persistent storage with standard recovery patterns. A buyer who carries the Advanced tier across the cluster fleet without a tier by tier reading typically pays the Advanced premium on clusters that consume only Essentials features.

The discipline at the renewal table reads the tier per cluster against the actual feature consumption. A cluster that runs application persistent volumes and object buckets for an internal registry consumes Essentials features. A cluster that runs cross region object replication or multi cluster Ceph federation consumes Advanced features. The aggregate tier line across the fleet sums the per cluster readings, and is often materially below the line that a uniform Advanced tier across the fleet produces.

ODF and Red Hat Ceph Storage carry the same Ceph engine underneath. The two product lines are commercial packaging variants of the same code base, sold for different consumption patterns and priced on different conventions. ODF reads per OpenShift worker node. Standalone Ceph reads per raw terabyte of cluster capacity. The two lines are not interchangeable at the renewal table, but the engine they license is the same.

The crossover matters for buyers who run both lines on the same estate. A buyer with an OpenShift cluster that uses ODF for application persistent volumes and an adjacent standalone Ceph cluster that serves object storage to external workloads carries two Red Hat storage lines on two different conventions. The reading at the renewal table is whether the two consumption patterns warrant two separate Ceph deployments or whether one of the two could absorb the other under the same line.

Three patterns appear in the practice's observation. The first is the warranted separation, where the OpenShift cluster's ODF consumption and the standalone Ceph cluster's object workload have genuinely different scale, performance, or operational requirements. The second is the legacy split, where the two lines exist because they were deployed at different times under different operational owners and the consumption pattern could now be consolidated. The third is the over deployment, where one of the two lines is provisioned at a scale that exceeds the actual consumption. Each pattern carries its own reading. For the standalone Ceph reading, see Red Hat Ceph Storage subscription explained.

OpenShift Data Foundation is one of the five component lines inside the OpenShift Plus bundle. A buyer who purchases the bundle on a cluster carries ODF as bundle scope on that cluster, whether or not the cluster's workloads actually consume ODF storage in production. The structural reading is that the bundle line covers ODF on every cluster in the bundle footprint, and the audit posture on the bundle reads the ODF entitlement across the same footprint.

The trap appears when the bundle is purchased across clusters that do not consume ODF. A buyer with twelve clusters in the bundle scope and ODF consumed on three of them carries the ODF line implicitly across all twelve through the bundle. The standalone ODF reading on the three clusters that consume ODF, paired with standalone OpenShift Container Platform on the other nine, often prices below the bundle line across the twelve when ODF is the only bundle component on the unused nine clusters that the buyer would otherwise consume.

The reading at signature names which clusters consume which bundle components, including ODF. A subscription assessment in the ninety days before signature produces the cluster by cluster consumption record, and the bundle line is then sized against the clusters that consume all five bundle components rather than across the broader OpenShift footprint. For the bundle math reading in detail, see when the bundle pays.

The renewal table on OpenShift Data Foundation reads three variables: the worker node count on the clusters that consume ODF, the tier overlay between Essentials and Advanced per cluster, and the bundle inclusion question on the OpenShift Plus line. The reading separates the three, sizes each against actual consumption, and surfaces whether the bundle inclusion is justified by the broader bundle component consumption on the same cluster set.

The cluster reading inventories every OpenShift cluster in the estate, identifies which clusters consume ODF in production, sizes the ODF line against the worker node count on those clusters, and reads the tier per cluster against the actual feature consumption. The bundle reading separately compares the standalone ODF line on the consuming clusters plus the standalone OpenShift Container Platform line on the non consuming clusters against the bundle line on the broader footprint.

The buyer side discipline holds across the term through a quarterly cluster inventory that tracks worker node count, ODF consumption, and tier feature use per cluster. The audit notice on an ODF line reads against the cluster inventory at the time the audit covers. The defensive discipline is to maintain the inventory in a form the buyer can produce on demand, so the audit reads against the buyer's record rather than against the field team's read of the deployment.

For the broader storage practice context, see the storage and virtualization practice. For the standalone Ceph reading, see Red Hat Ceph Storage subscription explained. For the CSI crossover reading, see CSI entitlement crossover. 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.