Disk Throughput by Sandbox Size, Measured With fio
Updated October 27, 2026 .md
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 |
| 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.
smallhad the highest sequential write median andlargethe 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. - 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=1skips 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:
# 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-roThe 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:
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=jsonEach 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:
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.json869.883443 MB/s 212372.854238 IOPS 150.373648274 usTo repeat it, this is how our script created each sandbox and installed fio (it then ran the four commands above):
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"fio-3.36After 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 installstresses 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#
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.