metrics
[0]
▼Photo upload time
8–12↑
▼Database size
50 GB↑
●DB connections
45/100
architecture
[1]
Before: Photos as BLOBs
+-----------+    INSERT image bytes    +-------------+
|  Web/API  | -----------------------> |   Database  |
| (HTTP)    |                          |  photos(img)|
+-----+-----+    SELECT image bytes    +------+------+ 
      |  ^  <-------------------------------+
      |  |           BLOBs live here        |
      v  |
   Clients
(8–12s upload @3MB; backups heavy)

Single web + single SQL DB; images stored as BLOBs

story
[2]
$cdstage_q1[1/6]
# The Basic Upload (10K users)

You made a dinky photo app for six friends and a dog. Then someone posted it to a forum. Now uploads crawl like a Victorian novel's plot. Your single database is hoarding image bytes like a dragon sitting on gold—impressive, but impractical. Backups are operas; uploads are epics.

Photos are stored as BLOBs (Binary Large Objects) directly in the PostgreSQL database. This seems simple, but it has brutal side effects: the database buffer cache fills up with photo bytes instead of useful metadata rows. Backups balloon to hundreds of gigabytes. Replication slows to a crawl copying binary blobs. Long-running writes hold locks. The database is optimized for small, structured, indexed data—not 5MB JPEGs.

[?]
Databases excel at structured, relational data and indexed queries—not serving large blobs. Where should the bytes live?
$selectstrategy↑↓ j/k enter
→Rent a bigger Postgres box and pray
Stream photos to object storage, keep URLs in Postgres
Launch a full media service with replication and CDN day one
Scaling a Photo-Sharing App|stage 1/6
▓░░░░░17%
^→ nav|↑↓ select