In this chapter
We'll put file storage and object storage directly side by side — genuinely different real tools for genuinely different access patterns, not a strict upgrade — and land on GreenMart's own correct real split: product images and receipts move to object storage, while application code and active logs stay on file storage.
The Problem in Real Life
Mike finally asks the practical, real question. "So which one do we actually use? Everywhere, or just for the images and receipts?"
Sarah shakes her head. "Not everywhere. This isn't a strict upgrade — it's a genuinely different real tool, for a genuinely different real job."
If object storage is this good, why don't we just use it for everything?
Mike
Two Real Tools, Not One Upgraded Version of the Other
Two real tools, not a hierarchy
File storage offers fine-grained editing and real structure; object storage offers flat, simple, unbounded scale — genuinely different jobs.
A real, repeatable decision framework
In-place editing needs, folder depth, write-once/read-many patterns, and scale each point toward the tool actually built for it.
Object Storage vs. File Storage
File storage and object storage aren't a worse option and a better one — they're built for genuinely different real access patterns, and choosing correctly means matching the real shape of GreenMart's own data to the model actually built for it, the same real discipline Act 2's own closing chapter applied to browser storage.
- Structure and editing — file storage's real strength. A real file system (Act 3) supports genuine, fine-grained operations object storage deliberately doesn't: opening a file and appending to it, real hard links sharing one inode across multiple names, a genuine hierarchical directory structure with fast, metadata-only renames. Anything GreenMart needs to open, partially modify, or organize with real nested structure belongs on file storage — a database's own data files, application logs actively being written to, configuration.
- Scale and simplicity — object storage's real strength. Object storage deliberately gives up that fine-grained editing in exchange for a genuinely flat, simple model that scales to an effectively unbounded number of objects, spread automatically across as many real machines as growth requires, with no single server's own disk as a real ceiling. Anything GreenMart writes once and reads many times, at genuinely large and growing scale, belongs here — product images, receipts, backups, exported reports.
- Permissions — the same real concept, a genuinely different shape. Act 3's own owner/group/other model doesn't carry over directly; object storage instead typically uses real, explicit policies attached to a bucket or even an individual object — "this bucket is publicly readable but only this application can write to it" — a real, different mechanism solving a related but not identical problem.
- GreenMart's own, real, correct split. The application's own code, its actively-written logs, and the database's own data files stay on file storage — they need real, fine-grained access and live on a server GreenMart actively operates. Product images and customer receipts move to object storage — write-once, read-many, growing without a real ceiling, exactly the pattern this Act's own second chapter described. This isn't replacing file storage; it's using each real tool for the real job it was actually built for.
| Real Question | Favors |
|---|---|
| Needs real, in-place partial editing (append, modify a few bytes)? | File storage |
| Needs a real, deep, nested folder hierarchy? | File storage |
| Written once, read many times, growing without a real ceiling? | Object storage |
| Needs to scale past what one server's own disk can hold? | Object storage |
| Actively used by a running process via normal file operations? | File storage |
This is the same real decision GreenMart's own migration needed — application code and active logs stay on file storage; product images and receipts move to object storage.
GreenMart closes this real comparison with a deliberate, correct split — not object storage replacing file storage everywhere, but each one doing exactly the real job it was built for, the same disciplined match-the-tool-to-the-data-shape decision this whole course keeps returning to.
Key Takeaway
Object storage and file storage aren't ranked better-and-worse — they're built for genuinely different real access patterns, and the right real choice is always about matching a specific piece of data's actual shape to the model actually designed for it.
Why This Matters
Every future data type GreenMart adds — a new kind of export, a new user-uploaded asset, a new internal log — now has a real, repeatable decision behind where it should actually live, instead of defaulting to whichever storage GreenMart already happens to be using.
GreenMart now has the real, complete framework for choosing between file and object storage, and its own migration plan: product images and receipts move to object storage; application code and active logs stay put. The next chapter goes deep on the real, practical mechanics of actually reading and writing objects: the object storage API.