S3 Server Benchmarks on PMSS
S3 Server Benchmarks on PMSS collects measured performance for the five self-hosted S3 servers documented on the S3 Object Storage on PMSS hub: rclone serve s3, versitygw, MinIO, SeaweedFS, and S3Proxy. The hub already lists each server's tested idle memory footprint; this page adds the other half of the picture — how fast each one moves data — so you can weigh weight against throughput when you pick one.
The numbers below are real, measured on one Pulsed Media storage box in a single sitting with one method for all five servers. They are a fair relative comparison of these servers against each other on the same disk, not an absolute rating of any one of them — read the method and caveats before quoting a figure.
Method
Everything was measured on a single unprivileged PMSS storage-box account, each server started in turn on its own non-default port bound to 127.0.0.1 and stopped before the next one, so no two servers competed for RAM or disk at once. One server ran at a time; the box was otherwise quiet.
- Client: the same client for every server —
rclone, which is pre-installed on every PMSS account — pointed at each local endpoint with path-style addressing. Using one client for all five keeps the comparison fair: any client overhead applies equally to everyone. These are therefore client-delivered rates — what a standard rclone client got out of each server — not each server's theoretical maximum. A server's own native client (for example MinIO'smc) may pull more from that particular server; the point here is one honest apples-to-apples client, not a per-server tuning contest. - Transport: loopback (
127.0.0.1). Measuring over loopback removes network variance and isolates what the server software plus the local disk can do. It is deliberately not a measurement of what you would see across the public internet — see the caveats. - Large-object throughput: a single 256 MiB object, PUT and then GET, repeated three times; the median run is reported in MiB/s. A 256 MiB object fits comfortably in the box's page cache, so the GET figures are largely served from RAM rather than re-read from disk — read them as a best case, and expect real cold reads from spinning or shared storage to be lower. The PUT figures are the more disk-honest half.
- What this measures, and what it does not: this is a bulk-transfer benchmark — one big object at a time. It deliberately does not report a small-object (many-tiny-files) rate. That workload is dominated by each server's per-object bookkeeping and durability behaviour rather than by bandwidth, it varies enormously between servers, and it is easy to measure misleadingly; rather than publish a fragile number we describe the trade-off in words below.
Memory is deliberately not re-reported here. The uniform client is itself rclone, which shares a process name with the rclone server, so a memory reading taken during an rclone run mixes the two. The clean, idle per-server RAM figures live on the hub and on each server's own page; use those.
Results
Bulk PUT and GET of a 256 MiB object, median of three runs, over loopback, same rclone client for all — figures in MiB/s.
| Server | PUT (MiB/s) | GET (MiB/s) |
|---|---|---|
| rclone serve s3 | 25 | 112 |
| versitygw | 22 | 146 |
| MinIO | 19 | 65 |
| SeaweedFS | 37 | 132 |
Reading it: all four move a large object at a healthy clip on the same disk. SeaweedFS led on writes and versitygw on reads, with rclone serve s3 close behind on both — and versitygw did it in the smallest memory footprint of the group. MinIO sat lowest here, which is the expected cost of the extra per-write bookkeeping a fuller S3 server does; you trade some raw speed for its versioning, policies, and console. GET is faster than PUT across the board because a 256 MiB read comes largely from cache (see the caveats) — read the PUT column as the more disk-honest one, and treat the whole table as a fair relative ranking of these servers on identical hardware, not an absolute speed you will see over a network.
S3Proxy is not in the table: its Java container did not finish cold-starting inside the measurement window on the test box, so there is no honest number to report for it here rather than a guessed one. Its deployment and footprint are covered on its own page.
What these numbers do not measure
A benchmark is only honest about what it actually did. This one deliberately leaves out several things that matter in production:
- Network reality. Loopback has no latency and effectively unlimited bandwidth. Over a real link, throughput is capped by your connection and by round-trip time, and the ordering between these servers can change. Treat the loopback figures as an upper bound on the server software, not as a speed you will see from home.
- Durability. None of these single-box servers survive the box failing. Raw speed says nothing about redundancy; when an object must outlive a whole box, cluster with Garage and accept the replication cost.
- Small objects behave differently. Bulk throughput does not predict how a server handles thousands of tiny objects. There, per-object overhead dominates, and the servers that give the strongest per-write durability guarantees (flushing and recording metadata for every object) are deliberately slower at it than one that simply drops each object on the filesystem as a plain file. If your workload is many small files rather than a few large ones, weigh durability against speed on each server's own page — and note that SeaweedFS is purpose-built for the many-small-files case that a bulk-transfer test does not exercise.
- Concurrency at scale. The test drives one client with modest parallelism. Behaviour under dozens of simultaneous clients is a different question this short run does not stress.
- Tuning. Every server ran at its stock defaults. Each can be tuned; these are out-of-the-box figures, which is what most people actually start from.
- One box, one run. A single account on a single storage box on a single day. Different hardware and different load will shift the absolute numbers.
See also
Each server has its own build-and-test how-to, and the S3 Object Storage on PMSS hub explains which one to reach for: the one-command rclone serve s3, the lightest-weight versitygw, the full-featured MinIO, the many-small-files SeaweedFS, and the bridge-and-proxy S3Proxy. For redundancy across boxes rather than raw speed on one, see Garage.
A companion writeup presents these same measurements for a general audience, alongside the wider self-hosted-S3-on-a-storage-box story.