Every photo on Instagram. Every video on Netflix. Every file in Dropbox. Every backup at every company. Every machine learning dataset at every AI lab.

They're all sitting in object storage.

Amazon S3 stores over 350 trillion objects. Not billion. trillion. If you printed each object's metadata on a sticky note, the stack would reach from Earth to the Moon and back about 450 times.

Object storage is arguably the most important storage innovation of the past two decades. It completely rethought how we store data, and in doing so, it made cloud computing possible. Before object storage, scaling storage meant buying bigger and bigger file servers. After object storage, scaling became as simple as uploading another file.

Forget directories. Forget hierarchies. Object storage uses a flat namespace. Every piece of data is an "object" with three parts:

1. The data itself, could be a 2 KB JSON file or a 5 TB video file
2. A unique key, a string that identifies this object (like photos/2026/04/sunset.jpg)
3. Metadata, key-value pairs describing the object (content type, upload date, custom tags)

That's it. No folders. Those slashes in the key? They're just characters in a string. photos/2026/04/sunset.jpg is not a file inside nested directories, it's a flat key that happens to contain slashes. The console might render it as if there are folders, but underneath, it's one big flat bucket of objects.

The HTTP access method is what makes object storage so powerful. Any device that can make an HTTP request can read or write objects. No special drivers. No mounted file systems. No NFS clients. Just a URL.

From a mobile upload through S3's triple replication to CDN delivery at the edge, this is why every photo-sharing, video-streaming, and file-hosting service runs on object storage.

Here's the secret to object storage's absurd scalability: it doesn't need to maintain a directory tree.

In a file system, creating a file requires updating the parent directory, allocating inodes, updating the journal, multiple coordinated writes. The deeper the directory tree, the more metadata operations per file. This creates bottlenecks.

Object storage throws all that away. Each object is independent. Storing object #1 and storing object #1,000,000,000,000 require the same amount of work. There's no tree to traverse, no directory to update, no parent-child relationships to maintain.

Behind the scenes, object storage systems distribute data across thousands of disks using consistent hashing or similar partitioning schemes. The key determines which servers store the object. Adding more servers adds more capacity, linearly, predictably, and without reorganizing existing data.

Amazon S3 is designed for 99.999999999% durability, that's eleven 9's. They achieve this by replicating each object across at least three physically separate facilities. You'd have to lose three separate buildings simultaneously to lose a single object. Statistically, if you stored 10 million objects in S3, you'd expect to lose one object every 10,000 years.

Object storage has one brutal limitation: you cannot modify an object in place.

With a file, you can open it, change line 47, and save. With an object, you have to download the entire thing, modify it locally, and upload a completely new version. For a 5 GB video file, that's a disaster if you just want to change one byte.

This makes object storage terrible for:

• Databases, they need to update individual rows/blocks constantly
• Application state, config files that change frequently
• Anything transactional, no ACID guarantees, no locks, no atomic multi-object updates

Object storage is also higher latency than block or file storage. A typical S3 GET request takes 50-200ms. That's fine for loading a webpage background image. It's not fine for a database reading a row 10,000 times per second.

The pattern that works: write once, read many times. Upload a photo, read it a million times. Upload a log file, analyze it later. Upload a ML model, download it to inference servers.

The pattern that breaks: write frequently, update in place. Edit a document repeatedly. Maintain a database. Track real-time state.

All three major cloud providers offer object storage that looks and behaves similarly. But the details matter when you are choosing a provider or building a multi-cloud strategy.

The most important takeaway: S3's API has become the de facto industry standard. Dozens of third-party tools (Terraform, rclone, MinIO) speak the S3 API natively. GCS supports it through an interop layer. Azure does not, which means switching from Azure to another provider requires more code changes.

Netflix stores every movie and TV show in S3. When you hit play, the video is served from their CDN, but the master copies, in every resolution and encoding, live in object storage. They store petabytes of video and spend millions per month on S3. It's still cheaper than running their own storage infrastructure.

Dropbox started on S3. Then, at massive scale, they built their own object storage system called Magic Pocket because they were spending over $75 million per year on S3. For most companies, S3 is cheaper. For Dropbox, whose entire product is storage, building their own made financial sense.

Snowflake separates compute from storage by keeping all data warehouse tables in object storage. When you run a query, compute nodes pull data from S3, process it, and return results. This means storage scales independently of compute, you pay for storage when idle, compute only when querying.