# Disk Throughput by Sandbox Size, Measured With fio

> Measured with fio on 2026-10-27 in eu-central, 3 runs per size, one sandbox at a time. small, default and large each read and wrote 1M blocks at a median 4,200 to 5,800 MB/s and handled 140,000 to 250,000 random 4k IOPS. Size made no clear difference. Results vary by host and neighbors.

Source: https://sandboxer.com/guides/disk-throughput-by-sandbox-size. Updated 2026-10-27.

**Short answer:** Measured with fio on 2026-10-27 in eu-central, 3 runs per size, one sandbox at a time. small, default and large each read and wrote 1M blocks at a median 4,200 to 5,800 MB/s and handled 140,000 to 250,000 random 4k IOPS. Size made no clear difference. Results vary by host and neighbors.

## Conditions

| | |
| - | - |
| Date and time | 2026-10-27, 10:07:33 to 10:33:11 UTC (`small` 10:07 to 10:14, `default` 10:18 to 10:25, `large` 10:25 to 10:33) |
| Region | `eu-central` |
| Sizes | `small` (2 vCPU, 4 GB), `default` (4 vCPU, 8 GB), `large` (8 vCPU, 16 GB), from the [machines docs](/docs/machines) |
| Tool | fio 3.36 from Ubuntu's archive (`sudo apt-get update && sudo apt-get install -y fio`) |
| Target | A 4 GB file in `/home/user` on the root filesystem: ext4 on `/dev/vda`, mounted `rw,noatime,discard` |
| Runs | 3 runs per size, 4 jobs per run, run one after another on one sandbox. One sandbox ran at a time, and each was deleted after its runs |
| Neighbors | Other sandboxes, including our own team's, were running on the platform during the window |

These are measurements of Sandboxer only. We didn't test any other service.

## Results

Median of 3 runs. MB/s is 1,000,000 bytes per second, as fio reports `bw_bytes`.

| Job | `small` | `default` | `large` |
| - | - | - | - |
| Sequential write, 1M blocks | 5,802 MB/s | 4,237 MB/s | 4,686 MB/s |
| Sequential read, 1M blocks | 4,391 MB/s | 4,871 MB/s | 5,358 MB/s |
| Random write, 4k, iodepth 32 | 154,088 IOPS (631 MB/s) | 140,882 IOPS (577 MB/s) | 149,728 IOPS (613 MB/s) |
| Random read, 4k, iodepth 32 | 219,655 IOPS (900 MB/s) | 248,831 IOPS (1,019 MB/s) | 189,655 IOPS (777 MB/s) |

Every run, so you can see the spread:

| Size | Job | Run 1 | Run 2 | Run 3 |
| - | - | - | - | - |
| `small` | Seq write MB/s | 4,707 | 7,288 | 5,802 |
| `small` | Seq read MB/s | 4,287 | 4,391 | 5,943 |
| `small` | Rand write IOPS | 156,227 | 146,059 | 154,088 |
| `small` | Rand read IOPS | 212,373 | 219,655 | 230,584 |
| `default` | Seq write MB/s | 4,237 | 4,094 | 5,716 |
| `default` | Seq read MB/s | 4,871 | 3,959 | 6,360 |
| `default` | Rand write IOPS | 140,033 | 140,882 | 147,011 |
| `default` | Rand read IOPS | 193,268 | 252,501 | 248,831 |
| `large` | Seq write MB/s | 3,826 | 5,396 | 4,686 |
| `large` | Seq read MB/s | 3,987 | 5,358 | 6,588 |
| `large` | Rand write IOPS | 149,728 | 141,313 | 156,555 |
| `large` | Rand read IOPS | 184,613 | 189,655 | 206,189 |

## How to read the numbers

- **Size didn't order the results.** For every job, the gap between the three size medians is no bigger than the spread between runs of a single size. `small` had the highest sequential write median and `large` the lowest random read median. Pick a size for its CPU, RAM and disk space, not for disk speed. For CPU results per size, see [CPU performance by sandbox size](/guides/cpu-performance-by-sandbox-size).
- **Sequential runs swing more than random ones.** The slowest and fastest of one size's three sequential runs differed by 39% to 65%. Random runs differed by 5% to 31%, and by 12% or less in five of the six cases.
- **Random 4k latency was low.** Mean completion latency at iodepth 32 was 126 to 228 microseconds across all random runs.
- **`--direct=1` skips the page cache inside the sandbox only.** It doesn't control caching on the machine underneath. Read these as what a program in the sandbox sees with a 4 GB working file, not as raw drive figures. A working set many times larger may behave differently.
- **One job, one queue.** Each job ran a single fio worker (`--numjobs=1`). Several processes writing at once, such as parallel builds or containers, can add up to a different total.

## Disk and filesystem per size

`df -hT /home/user` and `findmnt` in each sandbox before the runs:

```text
# small
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/root      ext4   19G  5.6G   13G  31% /
# default
/dev/root      ext4   56G  5.6G   51G  10% /
# large
/dev/root      ext4  130G  5.6G  124G   5% /

# all three
/dev/vda ext4   rw,noatime,discard,errors=remount-ro
```

The filesystem is larger than the size's listed disk (12, 50 and 125 GB) because the OS and pre-installed tools take about 5.6 GB and don't count against your space. Every size has one virtio disk, `/dev/vda`, with the `mq-deadline` I/O scheduler, on kernel `6.18.56-sandboxer`. The 4 GB test file fits comfortably even on `small`.

## The exact fio commands

Each command ran with `sbx exec <id> "<command>"`, in this order, three times per size:

```bash
fio --name=seqwrite --filename=/home/user/fio.test --size=4G --rw=write --bs=1M --iodepth=8 --numjobs=1 --ioengine=libaio --direct=1 --time_based --runtime=30 --ramp_time=5 --group_reporting --output-format=json
fio --name=seqread --filename=/home/user/fio.test --size=4G --rw=read --bs=1M --iodepth=8 --numjobs=1 --ioengine=libaio --direct=1 --time_based --runtime=30 --ramp_time=5 --group_reporting --output-format=json
fio --name=randwrite --filename=/home/user/fio.test --size=4G --rw=randwrite --bs=4k --iodepth=32 --numjobs=1 --ioengine=libaio --direct=1 --time_based --runtime=30 --ramp_time=5 --group_reporting --output-format=json
fio --name=randread --filename=/home/user/fio.test --size=4G --rw=randread --bs=4k --iodepth=32 --numjobs=1 --ioengine=libaio --direct=1 --time_based --runtime=30 --ramp_time=5 --group_reporting --output-format=json
```

Each job measures 30 seconds after a 5-second ramp that fio leaves out of the result. We pulled the figures from the JSON with `jq`:

```bash
jq -r '.jobs[0] | (if .read.io_bytes > 0 then .read else .write end)
  | "\(.bw_bytes/1e6) MB/s \(.iops) IOPS \(.lat_ns.mean/1000) us"' run1-randread.json
```

```text
869.883443 MB/s 212372.854238 IOPS 150.373648274 us
```

To repeat it, this is how our script created each sandbox and installed fio (it then ran the four commands above):

```bash
id=$(sbx new --type small --name aeo-disk-throughput-by-sandbox-size-small --no-env --ttl 3600 --json \
  | jq -r 'select(.event=="ready") | .id' | tail -1)
sbx exec $id --timeout 300 "sudo apt-get update -qq >/dev/null 2>&1; sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq fio >/dev/null 2>&1; fio --version"
```

```text
fio-3.36
```

After the last run it removed the test file with `sbx exec $id "rm -f /home/user/fio.test"`, then ran `sbx delete $id --yes`.

Run `apt-get update` first. On a fresh sandbox, `apt-get install fio` alone failed with `E: Unable to locate package fio` until we ran `apt-get update`. Delete the test file afterwards: snapshots save every file on the disk, so a stray 4 GB file counts toward your storage once you stop the sandbox.

## What we left out

- **`xlarge`.** We didn't test it; it needs the $100/month plan or higher.
- **Mixed read/write, fsync-heavy and small-file metadata workloads.** A database or `npm install` stresses the disk differently from these four jobs.

## FAQ

### Does a bigger sandbox have a faster disk?

Not in our runs. The medians for `small`, `default` and `large` sat within each other's run-to-run spread for all four jobs. A bigger size gives you more vCPU, RAM and disk space.

### Why use --direct=1?

It makes fio skip the sandbox's own page cache, so a read isn't answered from the sandbox's RAM. It doesn't control caching below the VM, which is why we report these as in-sandbox numbers.

### How much disk space do I get per size?

12 GB on `small`, 50 GB on `default`, 125 GB on `large` and 251 GB on `xlarge` for your files. `df -h` shows more because the OS and pre-installed tools sit on the same filesystem but don't count against that space.

### Will my numbers match these?

Probably not exactly. Our own three runs of one job differed by up to 65%. Results vary by host, by what other sandboxes on that host are doing, and by the time of day.

### What happens when the disk fills up?

Writes fail with `No space left on device`. Stop the sandbox and resume it at a bigger size; the filesystem grows on first boot.

## Related

- [How fast does a cloud sandbox start, resume and fork? Measured](/guides/how-fast-does-a-cloud-sandbox-start-resume-and-fork)
- [Fix exit code 137 or a full disk in a sandbox](/guides/fix-exit-code-137-or-a-full-disk-in-a-sandbox)
- [CPU performance by sandbox size, measured](/guides/cpu-performance-by-sandbox-size)
- [Machine sizes](/docs/machines)