ODF and raw Ceph, two prices, one engine.

Red Hat Ceph Storage and OpenShift Data Foundation are not two technologies. They are two product wrappers around the same underlying Ceph engine. Red Hat Ceph Storage is the standalone product. It runs on dedicated nodes, supplies block, file, and object storage to external consumers across the network, and is sold under a raw terabyte entitlement that meters the total physical capacity attached to OSD daemons1. The pricing model favours scale and disfavours small footprints.

OpenShift Data Foundation is the in cluster wrapper. ODF deploys Ceph as a set of pods inside the OpenShift cluster itself, using the cluster's own worker nodes for OSD scheduling and the cluster's local or attached disks for backing capacity. ODF is sold under a node level entitlement that bills against the OpenShift worker count or against an effective core figure on the OpenShift side. The pricing model favours embedded workloads that already pay for the OpenShift footprint and disfavours external consumers that do not2.

The buyer who reads the two products as separate things signs two contracts; the buyer who reads the two products as the same engine writes a single procurement narrative that names the workload and lets the procurement team route traffic between the two entitlements based on where the workload sits. The audit reads the two contracts independently and asks whether the right traffic ran on the right line.

The workload boundary that distinguishes ODF from raw Ceph is the storage consumer, not the storage operator. ODF is correctly licensed when the storage consumer is a workload inside the same OpenShift cluster: a stateful application, an OpenShift Virtualization virtual machine, an internal registry, a logging or monitoring pipeline. Raw Ceph is correctly licensed when the storage consumer sits outside the OpenShift cluster: a bare metal database, a VMware estate, a separate OpenShift cluster that consumes ceph from across the network, an external object workload.

The boundary blurs in three places that the practice observes. The first blur is the second OpenShift cluster that consumes storage from an ODF cluster across the network. ODF is licensed for the originating cluster; the second cluster is an external consumer and should ride a raw Ceph contract or its own ODF deployment. The audit reads the ceph cluster's client map and surfaces the second cluster's connections as external.

The second blur is the VMware estate that consumes object storage from an ODF deployment through the RGW radosgateway. The RGW endpoint is reachable from outside the OpenShift cluster, and a VMware consumer that mounts the bucket reads at the audit as an external workload on the ODF line. The buyer who runs object workloads at scale should route the external consumer to a raw Ceph contract3.

The third blur is the in cluster workload that grows past the node envelope the ODF contract assumed. ODF nodes scale linearly with the storage footprint up to a contract negotiated ceiling. A buyer who added storage by adding worker nodes that also schedule ODF OSD pods has scaled both the OpenShift footprint and the ODF footprint simultaneously, often without a procurement ticket. The audit reads the worker count against the ODF contract.

The economics of the choice between ODF and raw Ceph depend on the storage to compute ratio of the workload. A workload that needs heavy storage relative to its OpenShift footprint rides raw Ceph more cheaply, because the OpenShift node count cannot absorb the storage growth without scaling compute the workload does not need. A workload that needs light storage relative to a substantial OpenShift footprint rides ODF more cheaply, because the OpenShift footprint is already paid and the incremental storage is small.

The procurement function that prices both options at the same table can read the breakeven directly. Many platform engineering organisations carry both contracts simultaneously: ODF for the in cluster workloads where the OpenShift footprint is the driving cost, and a raw Ceph contract for the external workloads where the storage footprint is the driving cost. The two contracts share an engine but not an entitlement line, and the procurement function routes traffic between them through a written placement policy4.

The buyer who maintains a single contract across both patterns pays the misalignment in one direction or the other. An ODF only buyer pays for OpenShift node count growth that the workload does not need; a raw Ceph only buyer pays for raw capacity to back in cluster pods that ODF would absorb at no incremental storage line. The placement policy is the cheaper artefact.

The buyer side discipline is a workload map that names each storage consumer, the consuming cluster or estate, the access protocol, and the contract line under which the consumption is licensed. The map is reconciled against the ceph client map and the OpenShift worker count each quarter. Drift between the map and the live cluster surfaces as a procurement question before it surfaces as an audit question.

For the broader cross product reading, see the storage practice hub, the Ceph cluster sizing read for the raw side capacity math, the OpenShift Data Foundation pricing read for the node side entitlement detail, the Ceph Storage subscription read for the standalone entitlement model, and the VMware host inventory evidence read for the external consumer side that often involves a VMware estate. For the engagement protocol, see renewal negotiation and contact.

ODF and raw Ceph are two prices on one engine. The buyer who maps storage consumers against the entitlement boundary signs contracts that read cleanly at audit. The buyer who treats the two products as interchangeable pays the misalignment, either as OpenShift node growth that exceeds the workload's need or as raw capacity that ODF would have absorbed without an additional line. The placement policy is the cheapest piece of paper in the storage estate.

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.