Edge Cameras vs Cloud Vision: Where Processing Should Happen
Last updated:
The question that decides the hardware bill
A company planning vision on 40 cameras across five warehouses gets two quotes. One puts a small computer in every site and processes video locally. The other streams everything to the cloud. Both are technically sound. Their costs over three years differ enormously, and so do their failure modes when the internet goes down on a Monday morning.
Where processing happens is one of the first architectural decisions in any computer vision project, and it is often made by default: whatever the camera vendor sells. It deserves more thought than that. The trade-offs are the same ones covered in our broader post on edge AI and on-device inference, with video adding a lot of weight to the bandwidth side.
Three places vision can run
| Where | What it looks like | Strengths | Weaknesses |
|---|---|---|---|
| On the camera | Smart cameras with built-in AI chips | No extra hardware, lowest latency, video never leaves the device | Small models only, locked to vendor, harder to update |
| On-site edge box | A small GPU computer serving several cameras | Low latency, flexible models, works offline | Hardware to maintain at every site, physical security |
| Cloud | Streams or uploaded clips processed remotely | Heaviest models, easy updates, central management | Bandwidth, latency, ongoing compute cost, privacy exposure |
When edge processing is the right call
- Someone must act within seconds. A forklift proximity alert or a machine safety stop cannot wait for a round trip to a data centre.
- Bandwidth is limited or expensive. Continuous high-definition streams from many cameras quickly exceed a site's upload capacity, especially on rural or mobile connections.
- Video should not leave the premises. Processing locally and sending only counts or events is a strong privacy position and easier to explain to staff and customers.
- The site must keep working offline. Construction sites, farms and vessels lose connectivity regularly.
- Camera numbers are high. Cloud compute costs for continuous streams scale directly with camera count and hours.
Small, efficient vision models have improved a great deal, and the kind of detection most business projects need, people, vehicles, pallets, PPE, runs comfortably on modest edge hardware.
When the cloud makes more sense
- Analysis runs on recorded footage in batches, such as overnight footfall or weekly safety trends
- Models are large, change often, or need capabilities too heavy for edge devices
- There are only a few cameras and connectivity is reliable
- You want to compare or aggregate across many sites centrally
- Nobody is available to look after hardware in remote locations
General multimodal models that can answer open questions about an image are a good example. They are largely cloud-hosted, and using them on sampled frames, not continuous video, keeps costs sane.
The hybrid pattern most projects end up with
- Cameras stream to an on-site box or run detection on the device
- The edge model detects events and computes counts continuously
- Only events, counts and short clips around events are sent to the cloud
- The cloud stores results, runs heavier second-opinion models on those clips, and serves dashboards
- Model updates are pushed from the cloud to edge devices on a controlled schedule
This keeps bandwidth low, keeps raw video local, and still gives central reporting and easier model improvement. It is also the pattern that handles connectivity loss well: the edge keeps working and syncs when the link returns.
Stream events, not video. It is the single decision that most changes the running cost of a camera system.
Costs people forget
| Cost | Edge | Cloud |
|---|---|---|
| Upfront hardware | Devices per site or per camera | Minimal |
| Ongoing compute | Electricity only | Scales with cameras, hours and model size |
| Bandwidth | Low | Can be the largest line for continuous streams |
| Maintenance | Site visits, hardware failures, patching | Mostly remote |
| Model updates | Fleet management needed | Straightforward |
| Security | Physical access to devices | Cloud account and data transit |
Illustratively, for a handful of cameras analysed overnight, cloud is almost always cheaper. For dozens of cameras running continuously, edge hardware often pays for itself within the first year or two. Run the numbers for your own camera count and hours before choosing.
Do not forget the camera side either. Many older cameras compress video heavily to save recorder storage, and heavy compression smears exactly the fine detail a model needs. Raising the stream quality for the analytics feed, while leaving the recording stream as it is, can improve accuracy noticeably at no hardware cost. It is one of the first settings we check on site.
Operational realities of edge fleets
An edge device in a warehouse is a computer that someone will unplug to charge a radio. Plan for remote monitoring of device health, automatic restart, secure remote updates, encrypted local storage and a clear owner on site. Fleet management is dull and it is the difference between a system that works in year two and one that quietly stopped in month five.
When SpiderHunts designs these systems, we usually prototype in the cloud on recorded footage to prove the model, then move detection to the edge once accuracy and camera angles are settled. It avoids buying hardware for a model that turns out not to work. That approach runs through our machine learning projects, from shelf monitoring to site safety.
Frequently asked questions
What is edge computer vision?
Is edge AI cheaper than cloud for video analytics?
Can we run computer vision on our existing IP cameras?
Is edge processing better for privacy?
Planning a camera project and unsure where it should run?
Tell us how many cameras, where they are and how fast someone must act on what they see. We will sketch the architecture and the running costs before you buy hardware.