The Pi 4 Compute Module might support NVMe storage

There is a companion video to this post: Is fast NVMe storage coming to the Raspberry Pi?.

A couple days ago, Tom's Hardware posted an article stating NVMe support might be coming to the Raspberry Pi Compute Module 4.

On the first episode of The Pi Cast, Eben Upton, the CEO of Raspberry Pi, said "microSD will always be the baseline for storage", but "it's fairly likely we'll support NVMe soon on the Compute Module 4, to some degree, using single-lane PCI Express." (Skip to about 11 minutes into the video for the NVMe discussion).

He also said NVMe support is not without cost, since there's an extra connector silicon required. And with the System on a Chip used in the Pi 4, there's also a tradeoff involved: There's only one PCIe 1x lane, and it's currently used for the Pi 4's USB 3.0. If you want to add NVMe support, you'd have to drop the USB 3.0 ports.

For some people, the tradeoff might be worth it, though—but why?

NVMe vs SATA SSDs

What benefit does NVMe storage offer over other options like using a USB 3.0 SSD with UASP?

Well, this is an SATA (Serial ATA) SSD drive:

SATA SSD drive

And this is an NVMe (Non-Volatile Memory express) drive that uses the M.2 connector:

NVMe M.2 connector and controller chip - SSD

The main difference is the Serial ATA interface was originally designed in the year 2000 for hard drives that used slow spinning platters (and before that, many HDDs used IDE/Parallel ATA, which was slower still).

NVMe drives have similar guts to an SATA drive, but they directly attach to your computer's PCI express bus and bypass the overhead of the older SATA protocol.

An NVMe drive in the same price range generally performs better than an SATA SSD, and the difference will only get better over time, because the theoretical limit of NVMe storage is 32 GB/sec—most SATA drives are limited to 600 MB/sec:

SATA SSD vs NVMe theoretical performance limit

You can use either type of drive with a Raspberry Pi 4 via USB 3.0 if you have the right adapter, like this one for SATA drives, or this one for NVMe drives.

NVMe on the Compute Module 4?

With a new Compute Module 4, though, you might be able to plug an NVMe directly into the PCIe bus on the Raspberry Pi, instead of having to desolder the USB controller chip like you'd have to do on the Pi 4.

And as I mentioned earlier, that could have tradeoffs, because it sounds like Eben said it would incur more cost and would probably require more connectors. But people who use the Compute Module often have the resources to build custom PCBs and enclosures that pack the functionality they need into a tight space.

As an example, the Turing Pi board I've been using for my Raspberry Pi Cluster series packs a lot functionality into a Mini-ITX form factor, and can run seven Pi Compute Modules at the same time. It'd be cool if you could attach an NVMe drive to each one—it would make a much better-performing NAS or give me really fast storage for Kubernetes or other apps.

Compute Module 3+ vs Raspberry Pi 4 model B

One thing to keep in mind, though: we're talking about the Compute Module (current CM3+ pictured at top), not the regular Raspberry Pi 4 model B (pictured at bottom), which is the Pi 95% of people are familiar with. If there were a version of the Pi 4 available with a PCI express connection or an NVMe connection, it wouldn't fit into the same form factor and cases Raspberry Pi users are familiar with for all the model B computers since the original Pi.

PCIe NVMe M.2 adapter card with Pi 4 model B case

And to illustrate that example, the adapter pictured above would allow you to plug in standard M.2 NVMe drives into a 1x PCI Express slot that could work with the Pi 4, but it wouldn't fit into any standard Raspberry Pi 4 model B case. If a Pi had a built-in M.2 slot (versus PCIe), there are shorter NVMe drives which could fit, but not without increasing the clearance on the bottom of most Pi cases.

So I think, long-term, for most projects, it'll still be easiest to use a microSD card, and to pick a really good one, like the one I use and recommend, the Samsung Evo Plus. (See my 2019 microSD card review post for benchmarks and recommendations.)

Even if we might not be seeing an M.2 connector on the Raspberry Pi 4 model B anytime soon, it's still exciting to see the Raspberry Pi platform will be offering new possibilities with new hardware... hopefully within the next year or so!

Comments

Nice, but this is too late for me. Cause the actual I/O performance is ... was a problem for me. One year ago I build my Raspi Cluster for testing my microservices. I'm developing them on my PC and the Cluster is for "real" testing. My cluster have 8x Pi 4 4GB.

- Pi-4-Manager
- Pi-4-Data-Node-1/2
- Pi-4-Node-1/2/3/4
- Pi-4-Devel

On Pi-4-Manager runs:
- Gitea (mirroring ~1000 projects)
- Telegraf (collect metrics which are send to other Pi 3B+)
- Docker Swarm (+ Portainer)
- Nginx Proxy

On Pi-4-Data-Node-1 runs
- Eureka (Netflix Eureka service registry) Cluster Node 1
- Zipkin (distributed tracing system)
- Memcached Node 1
- Docker Node
- only one Java Microservice

On Pi-4-Data-Node-2 runs
- Eureka (Netflix Eureka service registry) Cluster Node 2
- Memcached Node 2
- Docker Node
- PostgreSQL 11 (at the moment 12 Databases)
- only one Java Microservice

On Pi-4-Node-1/2/3/4 runs
- on every node 10 runs 10 different Java Microservices
- Docker Node

- Pi-4-Devel
- runs some Java Clients for testing the cluster

The Java Microservices will be compiled on Pi-4-Manager and started over network on the pi's.

As my microservices grows and produces more load on PostgreSQL the performance (during heavy load) goes down. Cause write on microSD is not so fast. And I coudn't use some tools, which I wanted. Like Nexus Repository, ELK Stack. This was the reason that I setup a Mini PC with an Mobile CPU (4C/8T), 32GB RAM, 1x NVMe SSD and 1x SATAIII SSD to run all the tools (Gitea, PostgreSQL, ELK Stack, ...) which need better I/O. I will use my Raspi Cluster only for the Java Microservices. Now is the performance of the Java Microservices better, when the are using the PostgreSQL on the Mini-Server.

Have you tried using SSD external disks instead of micro SD cards ? There's a dramatic difference. I'm running a 4-pi cluster with 4 Samsung T5 SSDs (UASP enabled) , booting from disk, no SD at all....and I/O is blazing fast. (Lil' self promotion here :D https://github.com/pnavais/rpi4-ansible)
The cluster is based on ArchLinux ARM 64 bit with K3S + Ingress + Traefik (no Spring Cloud components , Eureka et al.) and Spring Boot microservices using Corretto 11 aarch64 , PostgreSQL 12. No problems so far...except for the lack of some ARM64 tools (SDKMAN is on the way), containers (e.g. Nexus 3)...however when no ARM container exists, most of the time it takes a few tweaks of a Dockerfile to make it work (Nexus is super easy to re-image for ARM).

However, after last moves from Microsoft and Apple, hopefully, ARM may get more love.

P.D: Little off-topic, i've just found out that K3OS provides a cloud-init OS (64 bit rootfs + userland for ARM64, Raspberry Pi boot files/firmware required though). Life can be wonderful, sometimes.

Sounds good. I know tat this is working but I didn't try this. Cause this is not a solution for me. On every Pi an SSD - make no sense & too expensive.

This is, why I habe now an Mini-PC as Mini-Server. ELK Stack need more SSD and CPU Speed.

SD Express, and microSD express extensions (https://en.wikipedia.org/wiki/SD_card#Bus) might be a middle ground

> It uses a single PCIe lane to provide full-duplex 985 MB/s transfer speed. Supporting cards must also implement the NVM Express storage access protocol. ... The Express bus re-uses the pin layout of UHS-II cards and reserves the space for additional two pins that may be introduced in the future.

> The microSD Express cards offer PCI Express and NVMe interfaces, as the June 2018 SD Express release did, alongside the legacy microSD interface for continued backwards compatibility.