Choosing Storage for Raspberry Pi 4/5: microSD vs USB SSD vs eMMC

The storage decision for Pi 4 and Pi 5 deployments

You need a bootable medium that survives the workload, fits the power budget, and can be replaced in the field. The wrong choice shows up as random read-only remounts, slow package installs, or a drive that never mounts after a power cycle.

For Pi 4 and Pi 5 the practical options are microSD, USB 3.0 SSD via SATA or NVMe enclosure, and eMMC modules on compute modules. The takeaway is to match write intensity and serviceability to the medium, not to pick the cheapest option up front.

Decision constraints

Constraints that drive the choice:

• Write endurance and workload: logging, databases, and continuous writes wear flash quickly.
• Boot support: Pi 4 and Pi 5 support USB mass storage boot with recent firmware and OS images. eMMC boot is native on Compute Module.
• Power: Pi USB ports share a limited 5V rail. Bus-powered SSDs can brown out without a powered hub.
• Serviceability: soldered eMMC is fast and low power but not field replaceable.

Options compared

Trade-offs by use case

microSD

Lowest cost and simplest boot. Suitable for read-heavy, low-write images such as kiosk or occasional use. High-endurance cards still have finite cycles and wear leveling is opaque. Avoid for continuous logging without a write buffer or overlay.

USB 3.0 SSD

Best sustained throughput and reliability for write-heavy workloads. Hot-pluggable and replaceable. Requires a recent Raspberry Pi OS image and firmware update for reliable USB boot. Bus-powered drives must be checked for current draw; if the drive resets or fails to mount, use a powered USB 3.0 hub.

eMMC

Near-SSD speeds with low power. Common on Pi Compute Module 4 and 5. Capacity is limited and the medium is non-replaceable, which is a risk for long life deployments. Good for permanent installs where power and form factor matter.

A common hybrid for mission-critical logging is microSD for OS boot and USB SSD for data. This limits OS writes and keeps data on more durable storage.

Validation example: confirm USB SSD performance on Pi

Run the checks on the Pi console or SSH session as root. These commands are destructive or read-only as noted.

Identify the device first with lsblk. Replace /dev/sda with the actual device.

Write speed check, destructive:

sudo dd if=/dev/zero of=/dev/sda bs=1M count=1000 oflag=direct

Run on the Pi with sudo privileges. This writes zeros to the block device. Only run on a freshly formatted drive you intend to erase. Expected check is a throughput in the 200–400 MB/s range for a healthy USB 3.0 SSD, but actual results vary by enclosure, cable, and Pi firmware version. Do not rely on a single run.

Read latency and throughput, read-only:

sudo hdparm -Tt /dev/sda

Run as root. The command reports cached and buffered reads. A result well above 250 MB/s suggests the USB 3.0 link is active. Verify the device is not a USB 2.0 fallback.

Boot time check:

systemd-analyze

Run after boot from the USB SSD. It reports kernel and userspace time. Boot time varies with OS image, firmware, and attached peripherals. Compare against a baseline on the same hardware.

Limitations to note. Firmware support for USB boot changes across Raspberry Pi OS releases. Verify current firmware with vcgencmd version and update via sudo rpi-update only after confirming the change is appropriate for your release. USB power issues can appear intermittently under load. The validation above is indicative, not proof of long-term reliability.