Object Storage

A large file does not have to be a database row

Images, videos, archives, backups, and other large binary objects are often more convenient in Object Storage. An object has a key, content, and metadata and lives inside a logical container or bucket.

bucket: user-media
key:    avatars/42/original.jpg
object: binary data + metadata

The application can keep only a reference and domain metadata in the primary database, while the bytes themselves live in object storage.

The model differs from a file system

Object Storage usually exposes an API that works with objects by key. A string such as avatars/42/original.jpg may look like a path, but “folders” are often only a convention in the key namespace rather than real directory hierarchy.

This makes it easier to distribute enormous numbers of objects and separates content storage from the local disk of a particular application server.

Access can be given directly

Instead of proxying every large file through the backend, an application can issue a time-limited link to the client or place a CDN in front of object storage. The application remains the control layer, while heavy data traffic follows a specialized path.

client -> application: request upload permission
client -> object storage: upload object
application -> database: save object metadata

The lifecycle must be managed

Large objects consume significant space, so retention rules, versions, and lifecycle policies matter. Old data can be moved to cheaper storage classes or automatically deleted after a defined period.

Access control also matters: a public object, a private user file, and a backup require different policies.