A storage design that works well for a dataset of photographs can behave very differently once audio and video are added to it. The three media types differ by orders of magnitude in file size, they are accessed in different patterns, and they place their processing load in different places. A single platform can serve all of them, but only if the design accounts for the differences rather than treating everything as generic unstructured data.
This matters more as organizations move past single-purpose models. A retail team that started with product images now has store video and call recordings. A healthcare organization has imaging studies, dictation audio and scanned documents in the same project. The infrastructure team ends up responsible for one platform that has to serve all of it without any one media type degrading the others.
Why mixed media breaks a single storage assumption
Most storage designs are tuned implicitly for one profile. A system sized for millions of small objects optimizes for request rate and metadata operations. A system sized for large sequential files optimizes for sustained bandwidth. Multimodal datasets contain both, often in the same training job, and the profile that dominates changes as the dataset grows.
The practical consequence is that a design validated on one media type can fail on another without anything obviously breaking. Image training that already suffers from small-file delays in the data loader does not get better when video is added; it gets a second, different bottleneck alongside the first, and the two compete for the same resources.
Capacity planning is affected as well. Video changes the shape of a capacity forecast entirely, because a modest number of hours of high resolution footage can outweigh millions of images. A forecast built on object count rather than volume will be wrong by a large margin the first time a video source is added.
The four things that vary across media types
When sizing a multimodal environment, four properties do most of the work in predicting behavior. They are worth establishing for each media source before any platform decision is made.
| Property | Images | Audio | Video |
|---|---|---|---|
| Typical object size | Kilobytes to a few megabytes | Hundreds of kilobytes to tens of megabytes | Hundreds of megabytes to many gigabytes |
| Objects per terabyte | Hundreds of thousands to millions | Tens of thousands | Hundreds to a few thousand |
| Dominant storage pressure | Request rate and metadata lookups | Mixed, depends on clip length | Sustained sequential bandwidth |
| Preprocessing cost | Decode and resize, moderate | Resampling and feature extraction, moderate | Decode and frame sampling, heavy |
| Access pattern in training | Random across the whole set | Random, often whole file | Partial reads of selected segments |
| Practical retention driver | Volume of sources | Consent and privacy rules | Capacity cost |
The last row in the access pattern is the one most often overlooked. Video training rarely uses every frame. It samples frames or short clips, which means the storage system is asked for ranges within large objects rather than whole objects. A platform that supports efficient range requests handles this without moving unnecessary data, and one that does not will read gigabytes to deliver seconds.
Where the payload lives and where the index lives
Multimodal datasets almost always need a catalog separate from the media itself. Training on video segments requires knowing which segments exist, where they sit inside which file, and what they are labelled. Training on audio requires transcripts or annotations aligned to time offsets. None of that belongs inside the media files.
The workable pattern keeps large media payloads on object storage and keeps the catalog in a database or in compact index files alongside them. The catalog is small, it changes frequently, and it needs query access. The payloads are large, they rarely change, and they need throughput. Separating them lets each be sized and protected appropriately, and it makes relabelling cheap because the labels are not embedded in terabytes of media.
This separation also simplifies the reproducibility problem. A dataset version for a multimodal set is largely a catalog snapshot plus object version identifiers, which is small enough to retain freely even when the media itself is measured in petabytes.
Object size is the decision that follows you
For images and short audio clips, the most consequential choice is whether samples are stored individually or packed into larger containers. Individual files are simple, easy to inspect and easy to update one at a time. Packed formats group thousands of samples into sequential files, which suits streaming reads and dramatically reduces per-object overhead.
The trade is flexibility. A packed file that contains 10,000 samples must be rewritten to remove one of them, which makes deletion requests and label corrections expensive. Teams working with personal data frequently find that the packed format they chose for performance has made compliance operations painful. A common compromise keeps the authoritative data as individual objects and generates packed copies for training, accepting the extra capacity in exchange for keeping both properties.
Video sits outside this decision because the files are already large. What matters there is chunking and container format: whether the system can retrieve a segment without reading the whole file, and whether the format supports that cleanly.
Video is a different problem from images
Video deserves separate treatment because it changes both the capacity plan and the compute plan. Decoding video is expensive enough that a training pipeline can become processor bound rather than storage bound, which makes it worth deciding deliberately where preprocessing runs. Many teams extract frames or embeddings once, store the derived form, and train from that. The derived dataset is far smaller and far faster to read, while the source video is retained for reprocessing later.
That produces a two tier arrangement that maps well onto storage design. The derived training set is comparatively small, accessed constantly and worth placing close to the cluster. The source video is large, accessed rarely and belongs on capacity storage with a retention policy attached. Treating both as one dataset on one tier is what makes multimodal environments expensive.
Resolution and codec decisions have a similar character. Retaining original resolution source material is defensible for a broadcaster or a medical imaging archive, and much harder to justify for footage that will only ever be sampled at low resolution for model training. That decision belongs to the data owner, but the infrastructure team should make its capacity consequence visible before it is made by default.
Where Scality RING fits in a multimodal design
Scality RING presents a single S3 namespace that holds objects of very different sizes without partitioning them into separate systems, which suits a dataset that contains millions of images alongside thousands of large video files. Range requests allow a training job to retrieve a segment of a large video object without transferring the whole file, so sampling behavior in the pipeline does not translate into wasted bandwidth.
Because RING scales capacity and throughput by adding nodes, a video source that multiplies the capacity forecast does not require a separate platform decision, and the catalog, derived datasets and source media can share one namespace with different prefixes, lifecycle rules and protection policies applied to each. Erasure coding can be applied to the large payloads where capacity efficiency matters most, which is the usual approach when weighing capacity against recovery behavior.
The design decision left to the team is which prefixes hold source material, which hold derived training sets and which hold the catalog, and what retention each one carries. Making those three distinct at the outset costs nothing and avoids a reorganization once the video volume arrives.
Judge the design by the slowest media type
A multimodal platform should be evaluated with a mixed workload rather than one media type at a time. Run image loading and video segment retrieval concurrently, at realistic ratios, and watch whether either degrades the other. The failure mode to look for is a small number of large sequential reads consuming the bandwidth that thousands of small requests were relying on.
Then check the operations that are not training: adding a new source, deleting a set of samples, relabelling a segment, and reprocessing source video into a new derived form. Those are the tasks that will be performed repeatedly over the life of the dataset, and a design that makes any of them slow will be worked around rather than used as intended.