11. Object / Blob Storage
1
The picture to keep in your head2
11.1 What's the difference between block, file and object storage?3
11.2 Why not just store files in the database?4
11.3 What are buckets, keys and metadata?5
11.4 How do uploads work with presigned URLs?6
11.5 How do you upload very large files reliably?7
11.6 How does object storage avoid losing files?8
11.7 What are storage classes and lifecycle rules?9
11.8 How should files be served to users?10
11.9 What happens after a file is uploaded?11
Memory card and where the analogy breaks12
Practice: five levels13
Interview questions14
Solutions15
Sources16
Code lab11. Object / Blob Storage
11.2 Why not just store files in the database?
3 min read+10 XP
At the cloakroom: You could stuff every guest's coat into the host's office filing cabinet next to the guest list. It would work for five coats. With five hundred, the cabinet jams, finding the guest list takes forever, and photocopying the cabinet for safekeeping takes all night.
In the system: Databases can store files (as BLOB or bytea columns), and for a few small files that's fine. At scale, it hurts:
- Size and cost: your database disk is the most expensive storage you have. Covers, PDFs and videos would make it many times bigger.
- Backups and replicas: every backup, every replica (Chapter 14) and every restore drags all those bytes along. A database that would restore in minutes now takes hours.
- Memory and cache: large values push useful rows out of the database's memory, slowing every query.
- Serving: every image download goes through your app and your database, instead of straight from storage or a CDN.
The standard pattern: put the file in object storage, and put the key and metadata in the database:
books table: id = 42 | title = "Designing Systems" | cover_key = "covers/42/large.jpg"
object store: covers/42/large.jpg → (380 KB of JPEG bytes)
The database stays small and fast; the object store does what it's built for.
Memory code: "The database keeps the token, not the coat."