Edge vs cloud: where the computing happens
Whether a smart home or building does its thinking on the device, on a nearby hub, or in the cloud shapes its speed, privacy and what keeps working offline.
Every intelligent environment has to decide the same thing over and over: when a sensor notices something, where should the thinking about it happen? A motion sensor trips in a hallway. Somewhere, a decision gets made about whether to switch on a light — and that “somewhere” might be a chip inside the sensor, a hub on a shelf, or a data centre on another continent. The choice sounds like plumbing, but it quietly sets how fast the system responds, how much it costs to run, how much of your daily life leaves the building, and whether anything works at all when the broadband drops.
This guide walks through the three usual places computing can sit — the edge, the “fog”, and the cloud — and why the split matters more than most product pages admit. None of the three is simply better. They trade against each other, and most real systems use a mix.
Three places to put the thinking
Cloud computing means sending data over the internet to be processed on servers you don’t own or see, then getting a result back. When you ask a voice assistant a question and it answers, the hard work usually happened in a data centre far away. The appeal is scale: near-limitless storage, heavy machine-learning models, and updates that reach every device at once. The catch is that everything depends on a working connection to that distant server.
Edge computing flips the geography. Instead of shipping raw data off to be processed, the work happens on or right next to the device that produced it — inside the sensor, on a smart-home hub, or on a small local server. The glossary entry for edge computing puts it plainly: process near the source to cut delay, network traffic and exposure. A light that turns on the instant you walk in is almost certainly running that rule locally, because a round trip to the cloud and back would be noticeable.
Fog computing is the awkward middle child. The term was coined by networking-equipment makers in the early 2010s to describe a layer that sits between individual devices and the distant cloud — think of a capable gateway, a local server in a plant room, or a neighbourhood cabinet that aggregates data from many nodes. Fog handles work that is too heavy for a tiny sensor but doesn’t need a data centre: combining readings from a whole floor, running a building-wide rule, buffering data during an outage. In practice the line between “edge” and “fog” is blurry, and plenty of people use “edge” to cover both. The useful idea is that computing lives on a ladder — device, local hub, regional node, cloud — and you can place each task on whichever rung suits it.
Why the location matters
Four pressures usually decide where a given piece of work belongs.
Latency. Latency is the delay between a cause and its effect — the gap between the sensor tripping and the light responding. For anything that should feel instant, or anything safety-related, a trip to the cloud and back is often too slow and too uncertain. Local processing answers in milliseconds because the packet never leaves the room.
Bandwidth and cost. A single camera or vibration sensor can generate a torrent of data. Streaming all of it to the cloud, all the time, costs money in connectivity and storage, and can saturate a modest connection. Doing the first pass locally — discarding the boring frames, sending only “a person appeared at 14:12” — cuts the volume dramatically. You pay to move conclusions, not raw footage.
Privacy. Data that never leaves the building can’t be intercepted in transit, retained on a server, or swept into someone else’s analytics. Keeping processing local is one of the strongest privacy levers an intelligent environment has, which is why it comes up repeatedly in our guide to privacy in intelligent environments. A radar sensor that decides “the room is occupied” on-chip and forwards only that fact reveals far less than one that streams a live feed to be analysed elsewhere.
Resilience. This is the one people notice only when it fails. If a decision depends on a distant server, then a broadband outage, a cloud provider’s bad day, or a company quietly shutting down a service can leave the device inert. Local logic keeps working when the wider internet doesn’t.
In short: the cloud gives you scale, storage and heavy models; the edge gives you speed, lower running costs, better privacy and something that still functions offline. Sensible systems put fast, private, safety-related work at the edge and reserve the cloud for the jobs that genuinely need it.
The outage test
The clearest way to feel the difference is to imagine the internet going down for an afternoon.
A motion-triggered light wired as a local automation — the sensor talks to a hub, the hub runs the rule — carries on exactly as before. It never needed the internet to switch a light; the connection was only ever for remote access and updates. Standards built around local control, such as the Matter and Thread stack, lean deliberately in this direction so that everyday actions don’t hinge on a distant server.
Now picture a cloud-dependent voice assistant in the same house. You say the wake word, the device lights up — and then nothing, because the speech it captured had to travel to a data centre to be understood, and that path is broken. The hardware is fine. The intelligence was somewhere else, and you can’t reach it. Cameras that store clips only in the cloud go blind for the duration; a thermostat that takes its schedule from an app may fall back to a dumb default. Same house, same power, wildly different behaviour, decided entirely by where each product chose to compute.
The lesson isn’t “never use the cloud”. It’s to know which of your everyday functions quietly depend on it, and to prefer local control for the things you’d hate to lose during an outage.
On-device inference and TinyML
For years, “real” machine learning meant big models on big servers. That has changed. TinyML — machine learning small enough to run on the low-power microcontrollers inside ordinary devices — lets useful inference happen with a trickle of power and no network at all. A model trained in the cloud can be shrunk and loaded onto a chip that then makes decisions by itself.
The everyday example is the wake word. When a smart speaker listens for its name, a tiny on-device model does that spotting locally; only after it triggers does audio go anywhere. That’s why the “always listening” part can happen without streaming everything you say to a server. The same trick spots a smashing window, recognises a gesture, tells a person from a passing car, or reads a hand-written temperature dial — all on the device. On-device inference is edge computing at its smallest: the answer is computed exactly where the data is born, and only the conclusion, if anything, travels onward.
Hybrid patterns that actually get used
Almost nothing serious is purely edge or purely cloud. The interesting designs split the work:
- Sense and filter locally, analyse in the cloud. The device does a first pass — motion detected, anomaly flagged — and forwards only the interesting events over a lightweight messaging channel for deeper analysis or long-term storage.
- Train in the cloud, run at the edge. Model-building needs lots of data and compute, so it happens centrally; the finished model is pushed out to devices that then infer on their own. Retrained versions arrive as updates.
- Local control, cloud convenience. The core automations run on a hub so they survive outages, while the cloud adds the extras — remote access from your phone, voice, dashboards, sharing across sites.
- Cache and forward. During an outage a fog node keeps buffering readings locally and syncs them once the link returns, so you lose responsiveness but not the record.
- Digital twins. A live digital twin of a building or plant usually lives centrally, fed by streams of edge-summarised data rather than raw sensor firehoses.
Understanding these splits is really about understanding the whole pipeline — sensing, connectivity, messaging and processing — which is the ground covered in our guide to how IoT works and across the wider Internet of Things topic.
The trade-offs, side by side
| Consideration | Edge (on-device / local hub) | Cloud (remote servers) |
|---|---|---|
| Response time | Milliseconds; no round trip | Depends on the connection; usually slower |
| Works during an outage | Yes, for local logic | No — the service is unreachable |
| Data that leaves the building | Little or none | Potentially a lot |
| Running cost | Low bandwidth; upfront hardware | Low hardware; ongoing bandwidth and fees |
| Compute power available | Limited by the device | Effectively unlimited |
| Heavy model training | Impractical | Well suited |
| Storage and history | Small, local | Large, long-term |
| Updating logic everywhere at once | Harder — reach each device | Easy — change it centrally |
| Long-term dependence on a vendor | Lower | Higher — the service can change or close |
How to think about it going forward
When you weigh up a device or a system, a useful habit is to ask a single question of each function: if the internet went down right now, would this still do its job? If the answer is no, that function is renting its intelligence from someone else’s computer, and you’re taking on their uptime, their pricing and their decisions about your data. Sometimes that’s a fair trade — a whole-city analytics platform belongs in the cloud, and so does anything that needs to learn from millions of examples. Often it isn’t, and a device that keeps the fast, private, everyday decisions local will serve you better for longer.
The direction of travel is towards more capable edges: cheaper chips, smaller models, and standards that assume local control by default, with the cloud invited in only where it earns its place. You don’t have to pick a side. You just have to know, for each thing that matters, where the thinking happens — and whether you’d be comfortable if that place went quiet.