In a controlled performance test, Shelby pushed a single gateway's client-facing network to its limit. Here's what we measured and where we're pushing next.
When you're moving large datasets, the storage layer shouldn't be what holds your network back.
That's what we set out to test in our latest performance run. And the results were encouraging.
In a dedicated performance environment, a single Shelby gateway drove its client-facing network to its usable capacity, with roughly 47-49 Gbps of outbound traffic recorded at the network interface.
We reached the limits of the network before we found the limits of Shelby. And that leaves us with an exciting question: how much further can we go?
The setup
The test ran through a single Shelby gateway connected to two load generators over 2×25 Gbps client links and to the storage backend over 2×100 Gbps links.
Behind the gateway were 16 RPC instances distributed across eight storage hosts.
We tested three workload types: read-only, write-only and simultaneous reads and writes.
For the read test, two load generators issued 128 concurrent whole-object reads across 3,800 objects ranging from 100 MiB to 1 GiB, totaling approximately 2.05 TiB.
What we saw
Once the read workload reached steady state, the client-facing links were effectively saturated. One of the two 25 Gbps links peaked at 24.6 Gbps.
Meanwhile, storage-provider reads completed in 56-60 milliseconds and the run completed without errors. No caching was used in the data path; all data was served from spinning disks.
Each load generator averaged around 23 Gbps of object payload throughput during its respective run.
With the client-facing network at capacity and no obvious signs of the storage backend struggling, the results suggest Shelby had more to give.
Why this matters
For a data platform built to support demanding workloads, this is an important performance milestone. One gateway. Two 25 Gbps client links. Both effectively saturated.
We're already seeing Shelby handle substantial data throughput in a controlled environment. And while we're still early, results like these give us confidence in the infrastructure we're building.
The next challenge is to push further, increasing available bandwidth, testing more demanding workloads and understanding how performance holds up as we scale.
What this result does and doesn't show
This was a controlled performance test, not a customer benchmark or a measure of Shelby's maximum backend throughput.
The test was designed to measure data throughput under controlled conditions, rather than replicate a full production deployment. Results may differ across other configurations and workloads.
We also tested write-only and mixed read/write workloads.
In the write-only test, the load generators reported a combined 42.45 Gbps of throughput. Under a mixed workload, the gateway's network interface recorded approximately 31 Gbps of writes and 33 Gbps of reads simultaneously during steady state.
These results provide further insight into Shelby's performance across different workloads and where we'll focus our next round of testing.
What's next: taking Shelby across regions
More bandwidth is the immediate next step, alongside further testing under more representative operating conditions, including concurrent workloads and multiple gateways.
But the next major milestone is cross-region performance.
Compute is becoming more distributed. Workloads can increasingly run across different regions and infrastructure providers, giving teams more choice over where and how they use compute.
The data layer needs to keep up with that flexibility.
Shelby is being built so workloads can access the same data across supported locations, without having to create and maintain another full copy every time their compute environment changes.
That’s the bigger opportunity, and the reason we’re testing it next.
We’ve shown that a single Shelby gateway can saturate its available client-facing network without hitting the limits of the storage backend. Now we’re taking that test across regions.