When I first started specifying edge computing hardware, I assumed the cheapest single-board computer was the obvious default. It runs the same containers. It boots the same Linux. Why would anyone pay two or three times more for an embedded computer module with a custom carrier PCB board?
Then I audited 18 months of RMA logs, SD card failures, and technician hours across 60 deployed devices. The "cheap" option wasn't cheap. But the premium option wasn't always justified either.
There is no universal answer to "what's the best edge hardware?" It depends on how many units you're deploying, what a failure costs you, and who's around to maintain it. So instead of one recommendation, here are three scenarios. Find the one that sounds like yours.
Edge vs. Fog Computing: The Budget-Relevant Difference
The terms "edge computing and fog computing" get used like they're interchangeable. They're not. In edge computing, processing happens on the device itself or very close to it — reading a sensor, classifying an image, controlling a motor. In fog computing, a gateway or local node aggregates data from several edge devices, filters it, and forwards it to the cloud.
Why should a procurement person care? Because fog nodes are more demanding machines. They need more CPU headroom, more storage, and better network throughput than a single edge device. A Raspberry Pi is a fine edge device. As a fog node, it's usually underpowered. Figuring out which layer you're building might be the cheapest thing you do all year.
Scenario A: Prototyping, Internal Tools, and Small Deployments (Under 20 Units)
If you're validating an idea, running an internal dashboard, or deploying fewer than 20 devices in a controlled environment, a consumer single-board computer is the right call. Not a compromise. The right call.
A Raspberry Pi 4 or 5 is the obvious starting point, but there are solid single board computer Raspberry Pi alternative options like the Rock Pi 4 and the Orange Pi 5. Board costs generally range from $40 to around $110 at the time of writing; check current pricing before you commit. The market moves fast.
For a proof of concept, these boards are genuinely hard to beat. The hidden cost I'll call out from experience is the power supply. A cheap USB-C charger that came with one of our test kits caused random reboots every few days. We swapped to a $15 supply from a reputable brand. The reboots stopped. (Mental note: never skip the power supply specification again.)
If your deployment stays small, or you have a technician within arm's reach of every device, stop here. Buy the SBCs and move on.
Scenario B: 20–500 Production Units in the Field
This is where the biggest procurement mistake happens: taking the consumer SBC that worked great in the prototype and scaling it directly into production. It looks like a budget decision. It rarely is.
Here's a comparison we actually ran. We tested (A) Raspberry Pi 4 boards with SD cards against (B) a Raspberry Pi Compute Module carrier board with eMMC storage. The upfront difference was significant — setup A was roughly 30–40% cheaper per unit. On paper, the Pi 4s won.
Over 18 months, the Pi 4s produced 11 corrupted SD cards out of 60 units. Each one cost an hour of technician time, $12 for expedited shipping on a replacement card, and about $19 for the card itself. Roughly $46 per incident, excluding downtime. One incident delayed a client report by two days.
The compute module units: zero storage failures. Zero. Not because the module is magical — because eMMC storage doesn't corrupt on unexpected power loss the way consumer SD cards do.
When I put both options in our total cost spreadsheet, the Pi 4 route cost us about $2,800 more over that 18-month period. It wasn't the boards that cost us. It was everything around the boards.
This is where carrier board quality starts to matter. A common assumption is that a carrier PCB board is just a breakout adapter — pins exposed for convenience. In reality, the carrier board decides how well the compute module survives real-world conditions. The question everyone asks about a carrier board is "does it have the right connectors?" The question worth asking is "does it protect the compute module?" Fused inputs, transient voltage suppression, properly regulated power rails, industrial temperature ratings — none of these appear in a marketing spec sheet, but all of them show up in field failure rates.
To be fair, there are deployments where a budget carrier board is the right call. One of our customers deployed 80 units with a lower-end board because a technician is already on site every week. Downtime tolerance varies, and that's a real tradeoff, not an error.
But if a node failure means a six-hour drive, a client-facing interruption, or a missed SLA, then the carrier board is the main event. Don't scrimp there. The quality of your edge hardware is part of the quality of your service. Clients notice when their dashboards stay online, and they definitely notice when they don't. The extra $50 per unit is sometimes the cheapest marketing you'll never have to explain.
Scenario C: Global Scale, or No Appetite for Managing Hardware
There's a third path that cost-conscious teams overlook: don't buy hardware at all.
Platforms like Fastly Compute Edge let you run code directly on a distributed edge network. You write your logic in Rust, JavaScript, or Go, push it, and Fastly handles the infrastructure. No carrier board to source, no compute module to inventory, no stack of power adapters. The cost model is usage-based: a free tier covers the first 10 million requests per month, with per-request pricing after that.
This makes sense when your workload is event-driven and bursty — request processing, edge redirects, API authentication checks, A/B testing, content rewriting. If you need compute spread across hundreds of locations, a managed edge service is not the lazy choice. It's the cost-efficient one.
To counterbalance: a steady 24/7 streaming workload can cross the threshold where per-request fees exceed a dedicated server. Managed edge isn't automatically cheaper. It's cheaper for a specific workload shape, so estimate your request volume before committing either way.
And for the fog computing layer — if your architecture needs local aggregation points that buffer and filter data from edge devices before sending it to the cloud — you're back to buying hardware. The embedded computer module plus a solid carrier board is, in my experience, the sweet spot between reliability and cost. Full rack servers are overkill. Consumer SBCs are too fragile.
How to Tell Which Scenario You're In
Here's the checklist I run through before signing any edge hardware purchase:
- Unit count. Under 20 in a controlled environment? Scenario A. 20–500 in the field? Scenario B. Hundreds across multiple regions without local ops staff? Scenario C.
- Cost of failure. If a dead node is a nuisance, buy the cheaper board and sleep fine. If it's a contractual breach or a lost renewal, do the math on what reliability is worth before you look at unit prices.
- Field support. A technician an hour away changes your risk profile completely. A six-hour drive to the nearest site flips it in the other direction.
- Deployment lifespan. Consumer SBCs become obsolete quickly, and spares get hard to source. We once bought 50 units of a "Raspberry Pi alternative" board that vanished from the market eight months later; we still have 14 in the field we can't get replacements for.
There's a shorter version, and I believe it after years of tracking edge hardware costs: the cheapest unit is not the cheapest system. Count every replacement, every site visit, and every hour spent re-flashing a card before you commit to a bill of materials. My own failure numbers come from a particular fleet in manufacturing facilities; your environment and workload may behave differently. That's precisely why I'd rather you run the checklist than take my word as gospel.
In my opinion, the right edge hardware decision looks different depending on where you sit. And that's fine. Let the numbers make the call, not the opinions.
