Object Storage

Compared to block storage, the unit storage cost of object storage is typically one order of magnitude lower

The access latency of object storage is typically in the range of tens to hundreds of milliseconds, far higher than local SSD (microsecond-level) or memory (nanosecond-level).

P95表示95%的请求延迟低于该值，P99表示99%的请求延迟低于该值，高分位数指标专门捕捉尾部延迟严重程度

Object storage treats data as independent "objects," where each object contains the data itself, metadata, and a unique identifier, stored in a flat namespace, which is fundamentally different from traditional file storage (hierarchical directory structure) and block storage (fixed-size blocks mapped to disk sectors).

Object storage provides SDKs for more than ten mainstream languages including Java, Python, Go, C++, and Rust.

Keeping a cold backup channel for critical data is a low-cost insurance against prolonged degradation.

Most users have not set up separate fine-grained SLO monitoring for object storage.

Backup and archival workloads are insensitive to latency, so being slower does not immediately expose degradation.

Setting a P95 latency baseline for object storage and triggering an alert when the P95 value deviates significantly from the historical baseline can help teams spot problems in the early stage of degradation (for example, latency doubling without a full outage).

The read scalability brought by object storage comes at a cost: the consistency model becomes more complex, and caching and invalidation strategies need to be redesigned.

GitHub's new architecture decouples Git's reference layer from its object layer, and once the object layer is migrated to object storage, read operations can scale horizontally independently of the write path.

Once object storage decouples the read path, agents can fetch object data concurrently at large scale, and reads no longer need to pass through a bottleneck shared with writes.

Object storage itself does not provide strongly consistent directory notifications or lease mechanisms, so an additional metadata service (such as etcd, ZooKeeper, or a self-built coordination layer) is needed to manage segment visibility, versions, and merge states.

Object storage (such as S3-compatible interfaces) has become the mainstream carrier for large-scale AI datasets due to its near-unlimited scalability.

In an object storage scenario, issuing a range request to object storage only when the actual content of a specific object needs to be read is the key prerequisite for achieving acceptable latency through this decoupled design.

Updates to refs require strong consistency guarantees, whereas most object storage only provides eventual consistency, requiring additional metadata services or conditional write mechanisms to avoid conflicts.

Object storage lacks the directory semantics, file locks, and low-latency random access capabilities of a traditional file system.

Git can run on object storage if one is willing to regenerate packfiles.

HydraDB is built directly on top of object storage rather than relying on traditional local disks or self-managed storage layers.

Building on top of object storage reduces operational complexity, eliminating the need to manage storage nodes, handle disk failures, or manually scale capacity.