Distributed storage
We design and build Ceph storage for superintelligence (SI) work. Block volumes, object buckets and shared file systems come from one cluster.
One cluster, three ways in
Each workload reaches the same cluster in the form it needs.
Block volumes
Ceph block devices (RBD) for databases, indexes, virtual machines and Kubernetes, with snapshots and clones.
Kubernetes platformsObject storage
The Ceph Object Gateway (RGW) serves self-hosted S3-compatible object storage, with versioned buckets for datasets, raw captures, model weights, checkpoints and archives.
Shared file systems
The Ceph File System (CephFS): one file system that many training nodes read at once.
Where training data lives
Every kind of training data gets the storage that suits how it is written and read.
- DatasetsIn versioned buckets, so each training run can name the version it read.
- Raw capturesKept unchanged, next to what was built from them.
- CheckpointsWritten in bursts during training, and read back to resume.
- Model weightsStored by version.
- Shared working filesOn a shared file system every node can reach.
- Databases and indexesOn NVMe block volumes.
Replication or erasure coding per pool
Hot data sits on NVMe. Large, colder data sits on hard drives. Each pool gets the protection that suits its data.
Replicated NVMe
Fast pools for hot data, kept as whole copies on separate drives or servers.
Erasure-coded hard drives
Capacity pools for large, colder data, split into data chunks and parity chunks across drives or servers.
Placement
Data spread across drives, servers or racks, as the design sets out.
Growth
Drives and servers added while the cluster runs.
A design picks replication or erasure coding for each pool from how its data is written and read. Replication suits hot data that changes in small pieces, such as databases and indexes on block volumes. It answers small reads and writes faster and takes more raw capacity. Erasure coding suits large files written once and read in long runs, such as datasets, raw captures and archives. It takes less raw capacity, and costs more on small writes and when a drive is replaced and its data rebuilt.
Snapshots
Point-in-time copies of block volumes, for recovery and clones.
Versioned buckets
An overwrite keeps the version before it.
Delete protection
Deletes limited to the people and keys you name.
Snapshots and versioning are recovery features inside the cluster. They bring back an earlier version of a volume or an object after a change or a delete you want to undo.
How we size a Ceph cluster
A sizing starts from your data and from the GPU systems that read it. We choose the pools, drives, servers and storage network together.
Usable capacity is raw capacity divided by the protection overhead: whole copies for replicated pools, data plus parity chunks for erasure-coded pools.
- Data volumesHow much your datasets, checkpoints and model weights hold today, and how fast they grow.
- Reads and writesHow each kind of data is written and read: large files in long runs, many small files or checkpoint bursts.
- GPU systemsHow many GPUs read from the cluster, and the read and write rates training needs.
- Protection per poolReplication or erasure coding for each pool, which sets its protection overhead.
- Site and networkWhere the cluster runs, and the network between the storage and the GPU systems.
We run it ourselves
Our own platform runs on Ceph block, object and file storage, declared in Git. We build client clusters with the same patterns.
The Rillor platform- Block volumesDatabases and service volumes for our own products.
- Object storageS3-compatible buckets with versioning.
- Shared file systemsOne file system many services read at once.
Where it runs
On servers you own, on storage nodes we supply, or inside a private SI cloud.
Your servers
On-premises or in your colocation space, we build the cluster on servers you already own.
Storage nodes we supply
Storage nodes specified and delivered with your GPU systems.
GPU systemsInside a private SI cloud
The storage layer of a private SI environment.
Private SI cloud
How a storage project runs
Four steps, from your data today to a cluster your team runs.
Assess
We map what the storage must hold, how fast it grows, how it is read and written, and where it runs.
Design
We set the pools, the protection for each, the network, drives and servers, and agree the plan.
Deploy
We build the cluster, declared in Git, and test it under your workloads before it holds your data.
Hand over
Your team takes the cluster into service with its monitoring, its configuration in Git and a runbook to run it from.
Common questions
What is Ceph?
Ceph is distributed storage software. It spreads data across the drives of many servers and serves it from one cluster as block volumes, S3-compatible object storage and shared file systems. We design and build Ceph clusters for datasets, checkpoints and model weights, on your servers, on storage nodes we supply or inside a private SI cloud.
Is Ceph S3-compatible?
Yes. Ceph's object gateway serves S3-compatible buckets, so tools that read and write S3 can keep datasets, checkpoints and model weights in your own cluster. Versioned buckets keep the version before each overwrite, and deletes can be limited to the people and keys you name.
How do you size a Ceph cluster?
We start from how much data you hold, how fast it grows and how it is written and read, and from the GPU systems that read it. Each pool gets replication or erasure coding, and usable capacity is raw capacity divided by that protection overhead. We then choose the drives, servers and storage network together to give the capacity and the read and write rates training needs.
Research
The newest articles from our Insights library, each with a full research report and its sources.
- Ceph block, object and file storage: which workload uses whichCephFS vs RBD vs RGW, from Ceph's Umbrella 21.2.0 documentation: which workloads need a block device, a shared file system or S3-compatible object storage, and why.Distributed storage7 min readPDF report
- Self-hosted S3-compatible storage: Ceph RGW and the alternativesMinIO alternatives for self-hosted S3-compatible storage, compared from each project's own documentation and license as of 8 November 2026: Ceph RGW, SeaweedFS, RustFS, Garage, Apache Ozone and OpenStack Swift.Distributed storage7 min readPDF report
- Storage for model training: datasets, checkpoints and weightsStorage requirements for model training and checkpointing, from published sizes and measurements: datasets read on every pass, checkpoints written in bursts and weights kept by version.Distributed storage7 min readPDF report
Notices
Trademarks. NVIDIA, AMD, Ceph, Kubernetes and related product names are trademarks of their owners and are used only to identify products. No affiliation or endorsement is implied.