Glossary
Object storage
Object storage keeps data as self-contained objects, each made of the data itself, descriptive metadata and a unique key, in a flat namespace reached over the network, most often through the S3 API. Objects are written and replaced whole rather than edited in place, and capacity grows by adding servers.
What an object carries
- The data, from a few bytes to many terabytes, stored as one unit.
- A key, the unique name an application uses to write and read it.
- System metadata, such as size, creation time and version.
- Custom metadata, labels the application attaches, such as a patient study, a camera ID or a retention class.
Objects sit side by side in buckets, with no folder tree beneath them. A key such as projects/2026/scan-0412.dcm resembles a path, and tools display it as folders, but the slashes are only characters in a name. Lookups do not walk a hierarchy, so a bucket holding billions of objects answers a read as directly as one holding ten. Systems that follow the S3 API closely are described under S3-compatible storage.
Whole-object writes decide the fit
The single rule that sorts workloads is how data changes. A video editor that alters ten seconds of a 2 GB file on a file share rewrites only the affected blocks. On object storage the same change means uploading a new 2 GB object, or a new version of it. For data that is written once and then read, that costs nothing. For data rewritten in small pieces all day, it rules object storage out, whatever the file type or size.
| Workload | Fit | Reason |
|---|---|---|
| Backup repositories | Strong | Large files written once, kept for a set period, read at restore |
| Media and image archives | Strong | Write once, read many times, metadata useful for search |
| Analytics and AI datasets | Strong | Many parallel readers and high aggregate throughput |
| Databases and VM disks | Poor | Constant small in-place updates |
| Shared documents edited by teams | Poor | File locking and in-place edits are expected |
The poor fits belong on block storage or network-attached storage, and the trade-offs against file storage are set out in object storage vs NAS.
How object stores grow and stay intact
An object store is a distributed system: objects are spread across many servers, and capacity grows by adding more of them while the namespace stays the same. Protection comes from full copies or from erasure coding, which survives the loss of drives or whole servers with less raw capacity than three copies. Retention can be enforced on each object, and object lock keeps an object unchanged until a set date, which is why object stores are common backup targets.
Is object storage slow?
Each request carries more overhead than a local disk read, so a single small read takes longer than on block storage. The strength lies elsewhere: many clients reading and writing large objects in parallel, with aggregate throughput that rises as servers are added. Workloads judged by total throughput tend to do well; workloads judged by the response time of one tiny operation do not. Finding data is the other adjustment. With no folder tree, applications keep their own index of keys, or list objects by key prefix and query metadata, and folder names that once carried meaning have to move into keys or labels.
Frequently asked questions
Is object storage only for archives?
No. Archives are the best-known use, but backup repositories, analytics platforms and AI pipelines read and write object storage continuously. The limit is on rewriting part of an object, not on how often data is used.
Does object storage use a file system?
No. The namespace is flat. Tools show a folder view by treating slashes in keys as separators, but no directory tree exists underneath.