Object Storage: What It Is Not

You can store anything in it. That does not mean you should use it for everything.

The three wrong uses, and why they fail

Object storage — S3 and its equivalents — is built around a single model: write a blob, retrieve it by key, version it cheaply, replicate it durably across failure domains. That model is genuinely excellent. It is also so simple that engineers routinely mistake "stores bytes" for "works like a filesystem," and the mistakes are predictable enough to catalogue.

It is not a filesystem. The flat namespace with slash-delimited key prefixes looks like a directory tree; it is not one. There is no atomic rename — "move" is a copy followed by a delete, with a window of duplication in between. There is no append, only overwrite. Listing a prefix at scale is slow and expensive. Applications ported from POSIX assumptions — file-locking, directory traversal, inode metadata — degrade badly or break outright. When you find yourself implementing advisory locks on top of object storage, you have already lost.

It is not a database. Object storage gives you strong read-after-write consistency on new puts (a property the major providers hardened in the early 2020s), but it offers no transactions, no secondary indexes, no range queries, and no way to update a field inside an object without rewriting the entire object. Engineers sometimes use it to store JSON blobs keyed by entity ID, which works fine for simple lookups — until they need to query by any attribute other than the key, and then they need a separate index anyway. At that point they have built a slow, expensive, operationally awkward database with none of the guarantees.

It is not a cache. Latency to object storage is measured in tens to hundreds of milliseconds per request, routed through an HTTP endpoint with SSL negotiation on cold connections. It sits behind a regional API, not on a memory bus. Anything that needs sub-millisecond reads — session state, hot configuration, real-time feature flags — requires a different tier entirely. Putting a CDN in front reduces latency for static assets served to end users, but that is the CDN doing the work; the object store is still a slow origin.

The common thread in all three failures is the same: object storage optimises for durability and throughput at scale, and it trades away everything that makes the other patterns work — in-place mutation, relational structure, latency. Those are not bugs waiting to be fixed. They are the architectural bargain that makes the cost and the durability possible.

Use it for what it is: a durable, cheap, infinitely scalable place to put blobs you retrieve by key. When you need anything else, name that need and reach for the right tool.