Object storage
A flat store for immutable blobs (objects) addressed by a key, with near-infinite scale and low cost. S3 is the canonical example. Optimized for writes-once, reads-many, not random writes. The backbone of files, backups, and data lakes.
- User files, media, backups, data lakes, static site assets.
- Anything large, immutable, and read-many.
- Transactional data, random writes, low-latency point reads (use a DB).
- Frequently updated small objects.
Definition
Object storage (S3, GCS, Azure Blob) stores objects in a flat namespace with metadata, accessed over HTTP. Objects are immutable (you replace, not edit). It scales to exabytes with 11 9s durability and per-request pricing.
Why it exists
Block/file storage doesn't scale to petabytes cheaply and isn't HTTP-addressable. Object storage gives cheap, durable, internet-native blob storage for everything from user uploads to backups and analytics.
How it works
PUT/GET objects by key. Strong consistency on writes (S3 since 2020). Lifecycle rules tier to cheaper storage or delete. Versioning keeps history. Multipart uploads handle large objects. No random in-place edits; rewrite to replace.
Scaling limits
No random writes or file-system semantics (no appends, no byte-range writes). Latency is tens of ms, not sub-ms. Not a database. Listing huge prefixes is slow; use key prefixes for partitioning.
Cost shape
Cheap storage per GB + per-request + egress. Blow-ups: egress to the internet, frequent LIST/GET on huge buckets, and over-long retention.
Alternatives
- Block storage — Random read/write and low latency, but expensive and not internet-native.
- Database BLOB — Transactional but costly and slow for large blobs.
Failure modes
- Egress costs surprising you.
- Listing large prefixes slowly.
- Accidental public exposure of private objects.