S3-compatible object storage, explained without the jargon

Object storage stores files as "objects" in "buckets" rather than folders on a disk. It has become the default way applications handle media, backups and user uploads — and "S3-compatible" is why.

**What "S3-compatible" means.** Amazon's S3 API became the de-facto standard for object storage. When a service is S3-compatible, tools written for S3 — SDKs, CLIs, backup software — work against it by changing only the endpoint URL. That portability is the whole point: your code is not locked to one provider.

**When to use object storage instead of a plain disk.** Use it when you are storing files that many servers or users need to reach, when the data will grow large, or when you want durable replication without managing RAID yourself. A local disk is fine for a small app; object storage is what you move to when the files outgrow one machine.

**The egress trap.** Many providers charge little for storing data and a lot for serving it back out — the "egress" fee. Before committing, understand the bandwidth cost, not just the storage cost. Some hosts include generous bandwidth, which is why it is worth comparing on the number that actually grows.

**Versioning and sharing.** Good object storage supports versioning, so an accidental overwrite does not destroy the previous file, and signed URLs, so you can share private files with links that expire instead of making everything public.

The mental model is simple: a bucket is a giant, reliable, shareable folder that every tool already knows how to talk to.