SeaweedFS volume servers keep a 16-byte per-blob index in memory for single-seek reads

A read in SeaweedFS does not touch the master. Clients cache the volume-to-server mapping and talk to volume servers directly, so the master never sits in the read path ^[9]. The volume server keeps a 16-byte index entry per blob in memory and resolves it in a single seek, including for erasure-coded data ^[8]. On disk each file costs 40 bytes of metadata ^[8]. Because the master tracks volumes and not files, a cluster holding billions of files still has only a few thousand volumes to account for ^[9].

Put a billion files through that model and the index is 16 GB of memory spread across the volume servers, with 40 GB of metadata on disk ^[1]. Small files are packed into append-only volume files, so there is no per-file inode and no per-file metadata file ^[20].

The claim SeaweedFS makes for the binary is broad. Its own README says one weed binary "serves an S3 object store, a POSIX file system, and a lakehouse with S3 Tables, all over the same data" ^[4].

RustFS starts differently. The documented command is a single docker run that publishes the S3 API on port 9000 and a console on port 9001 ^[13], and bare metal has a one-line installer fetched from rustfs.com ^[15]. Default credentials are rustfsadmin and rustfsadmin, the same string twice, and the dev.to write-up says you must rotate them before any production exposure ^[14].

The throughput figure attached to SeaweedFS is its README's own: 1 million 1KB files at concurrency 16 on a MacBook with an SSD, which the dev.to post calls unscientific and cites as a scale signal, not a hardware review ^[10]. For that number to say anything about your cluster, your objects would have to be about 1KB, your client would have to hold 16 requests in flight, the store would have to be one machine, and the disk would have to be a local SSD. Change any of those and you are reading a measurement of someone else's laptop.

So the decision comes down to interfaces. RustFS has no POSIX layer and no FUSE mount ^[7]. The dev.to comparison's rule is to pick SeaweedFS when you need a POSIX/FUSE mount, an Iceberg lakehouse, or billions of small files, and to pick RustFS when S3 is your only interface and a drop-in MinIO replacement in one docker run is the goal ^[18]. I think that split is right, and the deciding question is cheap to answer: list every consumer of the bucket and check whether any of them takes a path rather than a key.