microSD vs. NVMe on a Raspberry Pi 5: We Measured the Difference

A Raspberry Pi can run a perfectly useful Docker host from a microSD card. The more interesting question is what happens when that host stops being a quiet little computer and starts serving several applications at once.

We are building a four-node Raspberry Pi Swarm at Oddbyte. With an NVMe SSD and the bootstrap microSD still attached to the same Pi, we had a convenient opportunity to measure the difference instead of repeating the usual advice that an SSD is faster.

The result: roughly five times the sequential read throughput, and almost fifteen times the small random-read throughput when multiple requests were in flight. Those are measured storage results, not a claim that every application suddenly runs fifteen times faster.

Sequential read throughput on the same Raspberry Pi 5: microSD 92.5 MiB/s versus NVMe SSD 449.8 MiB/s, a 4.9-fold improvement. One MiB blocks, queue depth 16. — Sequential reads: 92.5 MiB/s on microSD and 449.8 MiB/s on SSD. Original chart by Aura / Oddbyte, using the median of three measured runs.

One Pi, two storage devices

The test machine was a Raspberry Pi 5 Model B Rev 1.1 running Debian 13. Its root filesystem was on a Samsung MZAL8256HDJD-00BL2 NVMe SSD, with a nominal capacity of 256 GB. The microSD device reported approximately 238.8 GiB and the controller name FE4S9; we did not independently establish its retail model or speed-class label.

Testing both devices on one machine removes the obvious problem with comparing a busy Pi on an old operating system against an idle Pi on a new one. This was still a short test on a live host, not a controlled hardware review. It compares these particular devices through this particular Pi.

Large reads: 92.5 versus 449.8 MiB/s

For sequential reads, fio used 1 MiB blocks with a queue depth of 16. The microSD delivered a median 92.5 MiB/s. The SSD delivered 449.8 MiB/s, making it 4.9 times faster.

That is a substantial improvement for workloads reading large amounts of data. It does not directly measure a backup restore: a restore also involves fetching, decrypting, decompressing, and writing data. Nor does it measure container image extraction, which includes plenty of writes and filesystem work.

The card was not embarrassingly slow in this test. The SSD simply provided much more read bandwidth.

The bigger difference appears under concurrency

Four KiB random reads: at queue depth one microSD achieves 7,155 IOPS and SSD 39,517; at queue depth 32 microSD achieves 7,521 and SSD 111,826. Each pair shares a zero-based linear scale. — Random-read throughput: the SSD advantage grows from 5.5× at queue depth one to 14.9× at queue depth 32. Original chart by Aura / Oddbyte.

We then switched to random reads using 4 KiB blocks. With one request in flight, the microSD completed 7,155 operations per second, while the SSD completed 39,517. That is a 5.5-fold advantage.

With 32 requests in flight, the microSD reached 7,521 operations per second. The SSD reached 111,826: 14.9 times the card’s throughput.

The distinction is useful. The card gained relatively little throughput when we increased concurrency. The SSD handled far more work when given several outstanding requests. A container host running multiple services can generate concurrent storage activity, so this is more relevant to our experiment than a large-file copy alone.

Queue depth 32 means 32 outstanding requests from the benchmark. It does not mean we tested 32 applications, or that a database will reproduce the same number. This was a synthetic random-read workload, not an application benchmark.

Latency: the small waits get smaller

Four KiB read completion latency at queue depth one: microSD mean 131.6 microseconds and 99th percentile 183.3; SSD mean 22.4 and 99th percentile 47.4. Lower is better. — Completion latency at queue depth one. Percentile values are medians of each run's 99th percentile, not a pooled percentile. Original chart by Aura / Oddbyte.

At queue depth one, mean read completion latency fell from 131.6 microseconds on microSD to 22.4 microseconds on SSD. The median of the runs’ 99th-percentile completion latencies was 183.3 microseconds for microSD and 47.4 microseconds for SSD.

Lower latency matters when work depends on finishing one small read before proceeding to the next. Faster storage can shorten those waits. It cannot eliminate time spent executing code, waiting on a network, or processing data that was already in RAM.

How we measured it

We used fio 3.39 with its libaio engine and direct I/O. The benchmark read the raw devices, beginning at a 1 GiB offset over a 2 GiB region. Direct I/O bypassed Linux’s page cache; it did not disable storage-controller caching.

Sequential: 1 MiB reads, queue depth 16.
Random: 4 KiB reads, tested separately at queue depths 1 and 32.
Duration: a two-second ramp followed by ten measured seconds per run.
Repetition: three runs for each device and workload, alternating which device went first between trials.
Reporting: medians of the three runs, with speedup ratios calculated from the unrounded median results.

The tests used fio’s --readonly guard. No benchmark data was written to either device. The Pi reported no throttling flags before or after the tests, and its temperature was approximately 48.5°C at the end.

Throughput is reported in MiB/s, not decimal MB/s. Latency here is fio completion latency, not the entire time an application takes to issue and process a request.

What this does—and does not—settle

For our small container cluster, the measurements make SSD boot and application storage an easy choice. We measured a clear read-performance improvement, especially when several requests were outstanding. That gives us a sensible reason to put the remaining nodes on SSDs before moving more workloads.

We have not yet measured write throughput, synchronous database commits, boot duration, endurance, sustained performance across a much larger region, or real application response times. SSDs also do not magically replicate application data between Swarm nodes. Those are separate experiments and design decisions.

The modest conclusion is enough: on this Pi, with these devices, the SSD delivered about five times the sequential read throughput and nearly fifteen times the concurrent random-read throughput. We do not need to turn that into a universal claim to call it a useful upgrade.