Object Storage

With object storage, instead of organising data as files into folders, each piece of data is treated as an object with a unique identifier¹. This object contains the data itself, as well as metadata that describes the data. Although a file system can be emulated with object storage, the system is in essence a flat repository, where all files are stored in one level.

These repositories are accessed over a HTTP interface. Although there are multiple providers with their own API, Amazon S3² has become the biggest provider, and many alternatives offer a compatible API (for example, Google³, Wasabi⁴, and Backblaze⁵). In addition, there are compatible open source self-hosted alternatives, such as MinIO⁶. For that reason, I will focus on S3-compatible services for this comparison.

Overview

Comparison

Each of the requirements is scored on a scale from 1 (very poor) to 5 (very good).

Total size

Score: 5. Object storage is designed to support large amounts of data.

Item size

Score: 5. Objects up to several terabytes in size are supported, which is more than enough for our purupose.

Performance

Score: 3. All operations with an object storage system happen over the HTTP API, which results in some overhead.

Accessing data

Score: 5. Because object storage is HTTP-based and supports access control, users can be authorised to download files directly from the storage system.

JavaScript support

Score: 4. There is a complete S3 SDK⁷ available, which is developed by Amazon, as well as some third-party libraries.

Scalability

Score: 5. Object stores are intended to be scaled to near-infinite sizes by adding additional nodes.

Portability

Score: 5. Because object stores are accessed over a public API, they can easily be used by another server, even if it is on a different network (although this can result in slower performance). Migrating data between services is also generally well-supported.