Garage's compatibility page marks versioning, Object Lock and encryption Missing

Garage's own S3 compatibility page marks bucket versioning as Missing ^[11], and Object Lock is Missing at every lock endpoint, legal hold and retention both ^[12]. Server-side encryption, PutBucketEncryption and its relatives, is Missing as well, and the project's stated position is that you encrypt at the partition or on the client instead ^[13]. Bucket replication through the S3 API is Missing ^[14], and ACLs and bucket policies are Missing because Garage has a permission model of its own, per access key and per bucket ^[15]. None of those rows are bugs; they are the project documenting that the feature is not implemented ^[25].

Counted against the RustFS README's available list, Garage matches two rows outright, S3 core and distributed operation, marks four as Missing, implements lifecycle in part, and substitutes its own permission model for IAM-style policies ^[23].

The license condition is narrow and specific. The Garage project states it plainly: "if you patch Garage and then use it to provide any service over a network, you must share your code" ^[8]. AGPL v3 is network copyleft, stronger than ordinary GPL, and the obligation attaches when you modify Garage and expose it as a service ^[9]. RustFS's README describes the project as "released under the permissible Apache 2.0 license", with no copyleft, so you can modify it and embed it in a closed-source product or a commercial service without disclosing source ^[10]. The dev.to write-up's view is that for a homelab or an internal-only deployment that never serves third parties, AGPL is usually a non-event ^[22].

The single-node path also costs Garage its design center. The quick start writes a garage.toml with metadata_dir, data_dir, replication_factor = 1 and ports 3900 through 3903 ^[18]. Garage's docs, meanwhile, describe a store that "replicates data 3x over distant servers" and is "not as latency sensitive" because it avoids consensus algorithms like Paxos or Raft ^[4].

The comparison does not include benchmarks; the dev.to write-up says "We cite the docs, not benchmarks" ^[20]. A feature table transfers to your deployment only when its rows match the calls your client actually emits. The check is which verbs your SDK or backup agent sends, and the write-up recommends testing first if the client assumes versioning, WORM immutability, SSE or IAM policies ^[24]. Two RustFS rows are still preview, MinIO on-disk compatibility and S3 Tables (Iceberg REST) ^[6], and RustFS has no POSIX layer and no FUSE mount ^[7]. The write-up's own rule is Garage for a tiny geo-distributed store on secondhand hardware when AGPL is fine. RustFS when the app needs versioning, immutability, IAM and a MinIO-compatible dialect on the smallest operational surface ^[21].