Raspberry Pi Compute Module 5: What's New, Carrier Boards, and Migrating from CM4

Our existing Compute Module coverage focuses on the CM4 and industrial carrier board use in general terms. The Compute Module 5 is the Pi 5's SoC in the same module form factor, and it changes enough - a new connector standard, a genuinely different performance tier, and a period of dual-support with CM4 - that anyone speccing new industrial or embedded hardware around a Raspberry Pi module needs to understand what actually moved between the two generations before committing to a design.

What's Actually New

SpecCM4CM5 SoCBCM2711 (Cortex-A72, quad-core, up to 1.5GHz)BCM2712 (Cortex-A76, quad-core, up to 2.4GHz) GPUVideoCore VIVideoCore VII RAM options1/2/4/8GB LPDDR42/4/8/16GB LPDDR4X eMMC/Lite options0/8/16/32GB eMMC or Lite (no eMMC)0/16/32/64GB eMMC or Lite (no eMMC) ConnectorTwo 100-pin high-density connectors (same family as CM3)New connector standard - not pin-compatible with CM4 carrier boards PCIeSingle-lane PCIe 2.0PCIe 2.0 x1 (with provisions depending on carrier board design) PowerExternal regulation required on carrier boardSimilar external regulation model, refined power sequencing RTCNot built inOnboard RTC (battery backup optional)

The performance jump (Cortex-A76 versus Cortex-A72, higher clocks, faster memory) mirrors the generational gap between the Pi 4 and Pi 5 covered in our Pi 5 vs Pi 4 comparison, which makes sense since the CM5 is fundamentally the Pi 5's silicon in module form. For CPU-bound workloads - local inference, video processing, anything currently CPU-limited on a CM4 deployment - this is a meaningful upgrade, not an incremental refresh.

The Connector Break Is the Big Deal

The CM4 and CM5 are not pin-compatible, and the connector itself changed - this means existing CM4 carrier boards do not accept a CM5 module, full stop. If you have an existing industrial deployment built around CM4 carrier boards, migrating to CM5 means a new carrier board design or sourcing a CM5-compatible board from your existing vendor, not a drop-in module swap. This is a meaningfully different situation than the CM3-to-CM4 transition, which also broke compatibility, so vendors in this space have been through this before and most CM4 carrier board manufacturers have announced or shipped CM5-compatible revisions.

Should You Design New Hardware Around CM4 or CM5 Right Now?

New designs starting today should default to CM5 unless a specific carrier board or peripheral you depend on genuinely lacks a CM5-compatible option yet - the performance and RAM ceiling are both meaningfully better, and CM4 will eventually reach end-of-life support the way CM3 did.
Existing CM4 deployments in production don't need to rush a migration - Raspberry Pi has historically committed to long production runs (often stated as through at least early-to-mid next decade for current modules) specifically for industrial customers who can't afford to redesign hardware on short notice.
Cost-sensitive designs should compare current CM4 Lite pricing against CM5 Lite pricing directly - the CM5 isn't strictly more expensive across the board, but configuration-for-configuration comparisons matter more than assuming either generation is the "budget" option.

Carrier Board Landscape

The official Raspberry Pi CM5 IO Board is the reference design and the easiest starting point for prototyping - it exposes the same general set of interfaces (dual HDMI, USB, Ethernet, camera/display connectors, PCIe) that the CM4 IO Board did, adjusted for the new connector and CM5's PCIe capabilities. Third-party carrier boards from established CM4 vendors (Ithaca, IQaudio-lineage boards, Waveshare, various industrial DIN-rail carriers) have been rolling out CM5-compatible revisions, generally maintaining similar mounting footprints and I/O breakout approaches even though the module connector itself is different - check current vendor catalogs rather than assuming feature parity by name, since board revisions vary.

Migration Checklist

Confirm your carrier board vendor has a CM5-compatible revision, or budget time for a new board design if you're rolling your own.
Re-verify power budget and thermal design - the CM5's higher clock speeds and Cortex-A76 cores draw more power under load than CM4's A72 cores, which can matter for passively cooled industrial enclosures that were tuned around CM4's thermal envelope.
Re-test any GPIO, I2C, or SPI peripheral wiring against the new carrier board's breakout, even if the pin functions are logically similar - physical pin locations and default states can differ between board revisions.
Update your OS image and bootloader to a Raspberry Pi OS release with CM5 support - older CM4-era images will not boot the new SoC.
Re-run your existing benchmarks or acceptance tests on the new hardware before committing to a full fleet swap, especially for latency-sensitive control applications.

Where CM5 Makes the Most Sense

Local AI inference at the edge (a natural pairing with the Hailo AI Kit content covered elsewhere on this site, once M.2/PCIe accelerator support matures on CM5 carrier boards), higher-resolution camera/machine vision pipelines, and any application currently CPU-bound on CM4 are the strongest cases for choosing CM5 today. Simple I/O-bound industrial control applications - reading sensors, driving relays, running a lightweight PLC-style loop - often won't benefit meaningfully from the extra CPU headroom and can reasonably stay on CM4 hardware where that carrier board ecosystem is already mature and deployed.

The Compute Module line exists specifically so industrial and embedded designers aren't stuck redesigning hardware every time Raspberry Pi ships a new consumer board - but the CM4-to-CM5 connector change means this generational jump does require carrier board work, not just a module swap. Plan the migration around your actual performance needs and carrier board vendor's timeline rather than assuming compatibility that isn't there.

Related Guides

Loading_