Ceph

What it is

Ceph is a distributed storage system that provides object (RADOS Gateway/S3), block (RBD), and file (CephFS) storage from a single unified cluster. No single point of failure by design — data is spread and replicated (or erasure-coded) across OSDs (Object Storage Daemons) with CRUSH algorithm handling placement without a central metadata lookup for data location. In Kubernetes environments it's almost always deployed via Rook, which handles the operator lifecycle, rather than run bare-metal.

Official description is not publicly available from the source data here, but functionally: it's the default answer when you need software-defined storage that scales to petabytes and don't want to pay for a SAN vendor.

Who builds it and why

Originated from Sage Weil's PhD work, later commercialized through Inktank, which Red Hat acquired in 2014. Red Hat remains the dominant corporate contributor and drives most paid support offerings. Governance now sits under the Ceph Foundation (Linux Foundation), with SUSE, Intel, Bloomberg, and others contributing engineering time.

2,236 contributors and continuous commits through mid-2026 signal this isn't a vendor side project — it's core infrastructure for companies running their own storage rather than renting it from a cloud provider. CNCF maturity is not publicly available because Ceph is not a CNCF project; it lives under the Ceph Foundation, separate governance track.

Production readiness signal

16,766 GitHub stars undersells actual production footprint — Ceph doesn't get stars, it gets deployed. Last commit 2026-07-01 shows active development, not maintenance mode. 2,236 contributors is a healthy, broad base, not a single-vendor-dominated project.

License is flagged as NOASSERTION in the repo metadata — worth checking manually before you build compliance paperwork around it; historically Ceph has been LGPL 2.1 for most components. Latest release isn't listed here — check the Ceph release page directly (Reef, Squid, etc. naming scheme) before planning upgrades, since Ceph has a defined release cadence with named versions and backport policies.

This is battle-tested software running at large scale (CERN, Bloomberg, DigitalOcean's storage backend, among others) for over a decade. The risk isn't "will it work" — it's "can your team operate it."

Who should use this

• Teams that need unified block+object+file storage and don't want three separate systems
• Organizations running private cloud (OpenStack, bare-metal Kubernetes) who need storage that isn't tied to a specific cloud vendor
• Anyone with the operational maturity to run distributed systems — dedicated storage/SRE function, not a side task for the app team
• Petabyte-scale use cases where cloud storage egress and per-GB costs actually matter

Who should NOT use this

• Small teams without dedicated ops capacity — Ceph has a real learning curve and failure modes (OSD flapping, PG stuck states, CRUSH map mistakes) that require genuine expertise to debug
• Anyone who just needs a PVC for a handful of stateful pods — local-path-provisioner or a cloud provider's CSI driver is less operational overhead
• Latency-sensitive workloads expecting NVMe-local performance — Ceph's replication/erasure-coding model adds overhead you won't escape
• Small clusters (under ~5 nodes) — Ceph's resilience model needs scale to pay off; below that, complexity outweighs benefit

Alternatives

• Rook + Longhorn — Longhorn is simpler, Kubernetes-native block storage; good if you don't need object/file storage too.
• MinIO — purpose-built S3-compatible object storage, far simpler ops model if object storage is all you need.
• Portworx / OpenEBS — commercial and open-source alternatives with different tradeoffs on complexity vs. feature completeness for K8s-native storage.

Pricing

Ceph itself is fully open source (LGPL 2.1, though license field shows NOASSERTION — verify before compliance sign-off). No license fees. Paid support is available through Red Hat (Ceph Storage subscriptions) and SUSE; running it unsupported is viable but requires in-house expertise you'll need to budget for in headcount, not license cost.