Blob / Object Storage

Bytes belong in object storage, pointers in the database

The single most common storage mistake juniors make is putting a 5 MB image, or worse a 500 MB video, into a database column. Relational and document databases are tuned for small, structured, frequently-queried rows. A large binary object (a "blob") is the opposite: big, opaque, write-once, read-many. Stuffing blobs into Postgres or MongoDB bloats the table, blows out your backup and replication times, wrecks the buffer cache (one video eviction flushes thousands of hot rows), and forces every byte to flow through your app servers. The right home for bytes is object storage: S3, Google Cloud Storage, or Azure Blob Storage.

The mental model is a split. Object storage holds the bytes; the database holds the metadata plus a pointer (the object key). A photos row stores id, owner_id, caption, width, height, content_type, and object_key = "photos/2026/u123/abc.jpg". The actual JPEG lives in the bucket at that key. Your DB stays small and fast; the blobs live somewhere built for them. Object stores give you flat key-value semantics (a key maps to an immutable object plus metadata), effectively unlimited capacity, and roughly eleven nines of durability (99.999999999 percent), achieved by replicating each object across multiple facilities.

Presigned URLs: keep bytes off your servers

When a client wants to upload, it asks your app server for permission. The app authorizes the user, then generates a short-lived, cryptographically signed URL that grants PUT to one specific key for, say, 15 minutes, and returns it. The client PUTs the file directly to S3. Downloads work the same way with a signed GET. Your app never touches the file body: it only mints capability tokens. This is what lets a tiny fleet of app servers support petabytes of transfer.

For large files use multipart upload: split the file into parts (say 8 MB each), upload parts in parallel, retry only failed parts, and finalize with a "complete" call that stitches them server-side. This gives resumability and parallel throughput. Where history matters enable versioning or write objects immutably with a content hash in the key.

The two cost and latency levers

Lifecycle and tiering: hot data stays in the standard tier, and a policy automatically moves objects to infrequent-access, then cold, then archive (S3 Glacier) as they age, cutting storage cost by 5 to 20x for data nobody reads. A CDN in front for reads: CloudFront or Cloudflare caches objects at edge PoPs near users, so a popular video is served from an edge 20 ms away instead of a single region 150 ms away, and your origin bucket sees a fraction of the traffic. You almost never serve public media directly from the bucket at scale.

Interview nuance: If asked "why not just base64 the image into a JSON column," the crisp answer is durability, cost, cache pollution, and egress path: object storage is cheaper per GB, more durable, and lets clients transfer directly via presigned URLs and a CDN, so bytes never bottleneck on your database or app tier.

  client --(1) ask to upload--> app server (authz) --(2) presigned PUT URL-->
  client --(3) PUT bytes directly--------------------------------> S3 bucket
                                                                     |
  DB row: {id, owner, key, w, h, type}  <--(4) app writes metadata--/
  read:  client <-- CDN edge cache <-- (signed GET) <-- S3 origin

Recap: Keep bytes in object storage with eleven-nines durability and only the key plus metadata in the DB, move files with presigned URLs and multipart upload so they bypass your servers, and control cost and latency with lifecycle tiering and a CDN.