Garage: Open-Source Distributed Object Storage

Original Article ↗ Hacker News Discussion ↗

Open‑source project Garage aims to provide S3‑compatible, distributed object storage that runs reliably on heterogeneous, consumer‑grade hardware, positioning itself as an alternative to systems like MinIO, Ceph, and SeaweedFS. Commenters explore trade‑offs between object stores and full POSIX file systems, debate the merits and shortcomings of the S3 API and AWS SigV4 authentication, and highlight Garage’s design choices such as CRDTs over Raft and deliberate simplicity over enterprise features. The thread also surfaces broader interest in content‑addressed and low‑latency storage backends, alongside practical reports of performance gains and operational challenges in real‑world deployments.

S3 compatibility and API debates

  • Many projects, including Garage, implement an S3-compatible API to reuse tooling and client libraries.
  • Some argue S3 is a “bad” interface (limited filesystem-like features, verbose, high-latency) and don’t see why it should be cloned.
  • Others counter that S3’s simplicity, early arrival, price, and vast ecosystem outweigh UI/API shortcomings; compatibility is highly valuable.
  • Debate over whether S3 really lacks metadata and structure; some point out paths, custom headers, and S3 Express improvements.

Object storage vs. filesystems

  • Several comments stress that implementing a fully featured distributed filesystem (POSIX semantics, directories, atomic renames, locks, multiple writers) is far harder than an object store.
  • Object stores relax consistency and update-in-place guarantees, making them easier to scale and better suited to large blobs, snapshots, and VM images, not interactive editing workloads.

Garage’s design goals and motivation

  • Aimed at S3-compatible distributed object storage for unreliable, heterogeneous, consumer-grade nodes (e.g., home servers, second-hand machines).
  • Designed around eventual consistency and “Dynamo-like” ideas; some parts of the layout system are formally proven.
  • Paired (RAID1-like) replication across locations is a deliberate, conservative design choice, not a limitation oversight.
  • Not positioned as a high-performance, feature-rich “enterprise” object store; more for self-hosting and small collectives.

Authentication and AWS SigV4

  • Some users find SigV4 cumbersome for simple use cases and would prefer basic-header-style API keys or anonymous access.
  • Counterpoint: S3 compatibility is a goal, and minimal SigV4 client implementations exist, though some still see them as unnecessary bloat.
  • Concerns raised about server-side handling of long-lived secrets with SigV4.

Comparisons and alternatives

  • Garage is compared to MinIO, SeaweedFS, Ceph, OpenStack Swift, Tahoe-LAFS, IPFS-based systems, Perkeep, lakeFS, and others.
  • One operator reports significant performance and reliability gains (especially with many small files and replication) after migrating a multi-petabyte workload from MinIO to Garage.
  • MinIO and Ceph are seen as more “enterprise-oriented” with richer feature sets; Garage prioritizes simplicity and different hardware assumptions.

Content-addressed and coordination-free storage

  • Multiple comments desire an “S3 for immutable blobs” with content addressing (e.g., BLAKE3 hashes), CRDT/coordination-free semantics, and QUIC/HTTP/3.
  • Various prior and related systems are mentioned, but many are seen as complex, over-scoped, or not clearly “production-grade.”