Why Object Storage Exists

In this chapter

We'll uncover the real, specific reason object storage exists at all — data that's write-once, read-many, and grows without a real ceiling, a pattern block and file storage were never designed to handle gracefully — and see exactly why GreenMart's own product images and receipts fit that pattern precisely.

7–9 min

The Problem in Real Life

Sarah draws two real lines on the whiteboard — one flat, one climbing. "This is roughly what a typical server's real workload looks like over time," she says, pointing at the flat one. "And this," pointing at the climbing one, "is GreenMart's product images and receipts. They don't behave like the same kind of problem at all."

Mike studies the gap between the two lines. "So we need... a different kind of storage, built for that second line specifically?"

Isn't storage just storage? Why would a different shape of data need a genuinely different system?

Mike

Storage Sized for a Server vs. Storage Sized for Forever

Write-once, read-many, unbounded growth

GreenMart's images and receipts are rarely edited, read often, and grow without any natural ceiling — a distinct real pattern.

Built to span many machines, not resize one

Object storage handles growth by adding real machines behind a simple interface, not by repeatedly resizing a single volume.

Object storage exists to solve a real, specific problem block and file storage were never designed for: real, unstructured data — images, receipts, backups, exports — that grows continuously, gets read far more than it's changed, and has no real reason to stay tied to any one server's own disk.

The real shape of the problem, precisely. GreenMart's product images and receipts share three real, specific traits: they're write-once, read-many (a receipt, once generated, is essentially never edited again — only read); they grow without a natural, predictable ceiling (every new order adds another receipt, forever); and they don't need the real, fine-grained structure a file system offers (no one needs to open a receipt "in place" and append to it byte by byte). This exact combination is genuinely common — and block storage's real, per-server ceiling makes it a poor long-term fit for it.
Why file storage (Act 3) doesn't solve this either. A traditional file system, however well-organized, still fundamentally lives on top of one real volume, on one real machine (or a small, tightly-coupled cluster of them) — the exact same real ceiling as block storage, just with a friendlier directory structure sitting on top. Deep, hierarchical folder structures are also a genuinely poor fit for GreenMart's own real access pattern: nobody needs to browse product images by folder path; they need to fetch one specific, known image, fast, by whatever identifier the app already has.
The real, different design object storage makes instead. Rather than one volume on one machine, object storage is built, from the ground up, to spread real data across many real machines — a genuinely distributed system underneath (this Act's own closing chapters go deep on exactly how), presenting one simple, flat, unbounded namespace to GreenMart on top. Growth isn't handled by resizing one disk; it's handled by the real system itself adding more real machines behind the scenes, invisibly, as data keeps growing.
A deliberately simpler real interface, in exchange for real structure given up. Object storage drops the fine-grained editing a file system offers (no real "open this file and change 10 bytes in the middle" operation) in exchange for a genuinely simpler, flatter real model — store a whole object under a key, fetch a whole object by that key. For data like GreenMart's own product images and receipts, which are read whole and rarely modified in place, this real trade costs almost nothing and buys real, practical, unbounded scale.

GreenMart now has the real, specific reason object storage exists at all: not as a fancier file system, but as a genuinely different design, built from the start for exactly the kind of write-once, ever-growing, simply-addressed data GreenMart's own product images and receipts actually are.

Key Takeaway

Object storage exists for data that's written once, read often, and grows without a real ceiling — trading a file system's fine-grained editing for a flat, simple key-based model built, underneath, to spread across as many real machines as growth actually requires.

Why This Matters

GreenMart's product images and receipts are exactly the real shape of data object storage was built for — recognizing that pattern is what turns "we keep running out of disk" into a specific, well-understood, solvable real architecture decision, rather than another disk resize six months from now.

GreenMart now has the real motivation behind object storage — genuinely different data, genuinely different design. The next chapter meets its actual real data model: objects, buckets, and keys.