What is object storage?
Object storage (Amazon S3, Google Cloud Storage) is a warehouse for FILES: you hand it a blob of bytes — a photo, a video, a PDF — under a name like photos/tonys/margherita-v2.jpg, and it hands back a URL. It keeps the file safe on multiple disks, effectively forever, for pennies per gigabyte.
It is deliberately dumber than a database. No queries, no indexes on the contents, no transactions across files — just three verbs done extremely well at any scale: put a file, get a file by name, delete a file. That narrow job is why it is roughly 10× cheaper per gigabyte than database storage and never needs "scaling" from you.
The rule of thumb that falls out: rows in the database, files in object storage, and a URL in the row to connect them. The database remembers that Tony has a margherita photo and where it lives; the bytes themselves live in the warehouse.
- object
- — one stored file plus its name — no structure inside
- bucket
- — a top-level named container for objects
- key
- — the object's full name/path within the bucket
Words to know
The database ate 2 terabytes of pizza photos
Early SliceNow took a shortcut: restaurant photos were stored INSIDE the database, bytes in a column. Five million photos at ~400KB each later, the database is 2TB — and 95% of it is photos. Nightly backups take 6 hours. Replicas take a day to rebuild. The actual DATA — orders, customers, menus — is a slim 100GB drowning in image bytes.
Worse, every photo view drags 400KB through the database connection — the same precious capacity the checkout path fights for. The database is a Formula 1 pit crew being asked to also run a furniture warehouse.
The fix is mechanical: move the bytes to object storage, keep a photo_url column. The database drops to 100GB (backups: minutes), and photo traffic leaves it entirely — because, as the CDN lesson showed, edges can pull static files straight from the warehouse.
Database before
2 TB (95% photos)
Database after
100 GB
Object storage cost
~1/10th per GB
Quick check
Which of these belongs in OBJECT storage?
One photo upload, traced end to end
Tony uploads a new margherita photo. The app server receives it and puts the bytes into the bucket under photos/tonys/margherita-v2.jpg — object storage answers with the URL. The app then writes ONE small row to the database: menu item 314, photo_url = that URL. Two systems, each doing the half it is good at.
Serving reverses it: a customer loads the menu, the app reads the row (5ms, tiny), and the URL lands in the page. Their phone fetches the image from the CDN, which on its first miss pulls from object storage — the origin from the CDN lesson. Note who never touches image bytes on the read path: your app servers and your database.
At bigger scale there is one more trick worth naming: the app can hand the phone a short-lived pre-signed upload URL, and the phone puts the 4MB directly into the bucket — the bytes never pass through your servers at all.
The full picture: where every kind of data lives
Four homes, one question each.
| Home | Holds | The question it answers |
|---|---|---|
| Database | Small, hot, queryable facts | "Which rows match this?" — safely, transactionally |
| Object storage | Big immutable blobs (photos, videos, PDFs) | "Give me this file by name" — cheap, durable, forever |
| Cache | Copies of recent answers | "Asked seconds ago?" — fast, allowed to forget |
| CDN edge | Copies of static files, per city | "Same file, but near the user" — geography's cache |
Tip — Objects love immutability
Object storage has no "edit" — you overwrite whole files. Lean into it: upload margherita-v2.jpg as a NEW object and update the URL in the database, exactly like the CDN lesson's versioned filenames. New name, instant cache miss everywhere, old file quietly deleted later. One habit solves storage updates and CDN invalidation at the same time.
Quick check
After the migration, a Sydney customer views a menu photo (already cached at their edge). Which systems handle the IMAGE BYTES on this request?
Match them up
Match each term to its plain meaning.
0/4 matched — tap a term on the left.
Build it yourself
Wire SliceNow's photo system: uploads go through the app to object storage with the URL saved in the database; customers view photos via the CDN. One palette piece would put us right back where we started — leave it off.
Apply it in an interview
Every design with user uploads — profile pictures, receipts, attachments — hides this same split. Practice spotting it in a full interview problem.