When you upload a photo to your phone, the backup lands in an invisible system that can store billions of objects: object storage. It is the technology that underpins photo services, backups, on-demand video and a good part of what is called the “cloud”. Understanding how it works helps to understand why the cloud is so cheap, so enormous and, at the same time, so different from a normal hard drive.
From the flat file to the object
A classic computer stores data in a hierarchical file system: folders within folders, with a path name like /photos/vacations/2026/image.jpg. That model works very well for a single user, but scales poorly when there are billions of files and thousands of servers writing at the same time.
Object storage removes the hierarchy. Each piece of data becomes an object: a block of bytes (the content) accompanied by metadata and a key, a unique identifier within a bucket, the logical container where objects are grouped. There are no folders or paths: only a flat space of keys.
The API that governs it: S3 and its clones
The de facto standard interface was set by Amazon with S3 (Simple Storage Service) in 2006. Its HTTP-based API defines very simple operations: PUT to upload an object, GET to retrieve it, DELETE to remove it and LIST to enumerate a bucket’s keys. Being pure HTTP, it works with any language and from anywhere on the internet.
That simplicity spawned a huge ecosystem: MinIO, Ceph or SeaweedFS implement the same S3 API, which makes it possible to set up your own object cloud on a home cluster without depending on a provider. It is the “same interface, different engine” pattern that has done so much for interoperability.
Where the bytes actually live: nodes and erasure coding
An object is not stored on a single disk. It is spread across nodes (servers) often distributed over several data centers. Here is where erasure coding comes in: the data is split into fragments and parity fragments are added, so that the full object can be reconstructed from a fraction of the fragments.
Imagine splitting a file into 12 fragments and storing 4 of parity: it is enough for 12 of the 16 to survive to recover the original. So a broken disk does not mean lost data, and you get 99.999999999% durability (eleven nines) at a much lower cost than replicating the whole file several times. Triple replication, the system many traditional systems use, still exists, but erasure coding is more space-efficient.
Consistency, versioning and lifecycle
Modern object systems offer versioning: each overwrite of a key creates a new version instead of destroying the previous one. That turns accidental deletion into something reversible, essential for backups and for defending against ransomware attacks.
They also manage the lifecycle. An object can start in a “hot” tier of fast access, move after 30 days to a cheaper “cold” tier, and to a “glacier” archive after 90 days. The tiers differ in latency and price per gigabyte; moving data automatically according to time rules optimizes cost without human intervention.
It is not a database (and it does not intend to be)
It is worth clarifying the boundary: object storage stores blobs (large binary blocks) and does not support relational queries, transactions or complex indexes. A photo, a video or a backup is an object; a user’s friend list is a database’s job. In practice, systems are combined: the database stores the metadata and “where it is”, and the object stores the heavy file. The division of labor is what allows each part to scale independently.
The real cost of the cloud
Object storage is cheap precisely because it is simple and massively parallel. A cluster can add nodes without stopping the service (horizontal scaling), spread the fragments automatically and rebalance when a node enters or leaves. That elasticity, combined with erasure coding, explains why storing a terabyte costs only a few euros per month.
It is, in short, the invisible layer on which the photos we upload, the videos we watch and the systems that keep everything we do not want to lose all rest. The next time your backup uploads “to the cloud”, now you know: you have been using a system of distributed objects, protected by parity and designed never to fail.
