Object storage is usually sized and priced by capacity: how many petabytes it holds and how fast it can move them. The second number that decides how a cluster behaves gets far less attention. It is the object count. A petabyte stored as a million large files and a petabyte stored as ten billion small ones are different systems to run, and most of the difference sits in metadata.
Every object carries a record describing it: its key, size, timestamps, checksums, version, access permissions, user-defined tags and the location of its data. That record has to be stored, indexed, protected and read on almost every request. As object counts climb into the billions, metadata becomes a workload of its own, with its own capacity limits, performance characteristics and failure modes.
The detailed inventory of what counts as metadata, and where it is physically held, is covered in the post on metadata residency. For sizing purposes, it helps to group it into three layers:
The first two scale with object count, not capacity. Doubling the number of objects roughly doubles their metadata, whether the objects are 4 KB or 4 GB each.
Most requests touch metadata before they touch data. A GET looks up the object record to find the data. A PUT writes a new record. A LIST walks an index. A HEAD reads only metadata. For large objects, the metadata step is a small fraction of the work. For small objects it can be most of it, which is why small object storage needs its own planning.
The effect is easiest to see by comparing the same capacity stored at different average object sizes.
| Capacity | Average object size | Approximate object count | Where pressure tends to appear |
|---|---|---|---|
| 1 PB | 1 GB | 1 million | Data throughput and network bandwidth |
| 1 PB | 10 MB | 100 million | Balanced between data and metadata |
| 1 PB | 1 MB | 1 billion | Metadata operations per second and index size |
| 1 PB | 100 KB | 10 billion | Metadata capacity, listing, lifecycle scans and repair bookkeeping |
Two clusters with the same capacity figure on a dashboard can therefore have very different headroom. The second figure worth reporting next to used capacity is the object count, broken down by bucket.
Listing is the operation most sensitive to object counts. Applications that list a bucket to find work, reconcile inventories or run backups issue requests that walk the bucket index page by page. In a bucket holding hundreds of millions of keys, a full listing is a long-running scan that consumes metadata resources the whole time it runs.
Key design matters. Prefixes that group related objects let applications list a small slice instead of the whole bucket. Keys that begin with a timestamp or a sequential identifier can concentrate new writes in one part of the index. Spreading data across several buckets, or across prefixes chosen for the access pattern, keeps individual indexes at a size where listing and lifecycle evaluation stay predictable.
Every version of an object has its own metadata record, and every delete on a versioned bucket adds a delete marker. A bucket with a hundred million current objects and an average of five versions each holds six hundred million records or more. Capacity reports show the bytes those versions use, as discussed in the post on S3 versioning costs, but the record count is what slows listings and lifecycle scans. Noncurrent version expiry is as much a metadata control as a capacity one.
Metadata has to be protected at least as carefully as data, because data without its record is unreachable. Metadata stores typically use replication, which is simpler to update in place than erasure coding, so a cluster holding billions of objects may carry several copies of a very large index.
Repair work also scales with object count. A rebuild after a drive or server failure has to identify every object with data on the failed component and restore its protection. With large objects that is a short list. With small ones it can be hundreds of millions of entries, and the bookkeeping, not the data movement, sets the pace. That is one reason rebuild times vary so much between clusters of similar capacity.
A sizing exercise that starts from object count as well as capacity usually asks:
The answers decide how metadata resources such as memory, fast storage and CPU should be sized relative to bulk capacity, and they are the inputs most often missing when a cluster runs out of headroom while still showing plenty of free space.
Scality RING is software-defined object and file storage that distributes data across the nodes in the system and is built to scale from petabytes upward on standard servers. Because it runs on hardware the customer selects, the balance between bulk capacity and the faster resources that metadata depends on can be chosen for the object counts and access patterns actually expected, rather than fixed by an appliance model.
RING is multi-tenant, with accounts and buckets that allow large datasets to be split along application or team lines, and it emits operational metrics and logs the operator keeps locally, so request mix, bucket growth and background activity can be tracked alongside capacity.
Capacity shows how much data a cluster holds. Object count shows how hard it has to work to keep track of it, and in most growing environments that is the number that runs out first.