Edge computing vs cloud computing in IoT is often framed like a debate.
Should data be processed at the edge?
Should everything go to the cloud?
Is edge replacing cloud?In real industrial IoT projects, I don’t think that is the most useful way to ask the question.
A better question is:
What should happen to the data before it reaches the cloud?
That is where things get interesting. It is also where devices such as the Robustel EG5120 edge computing gateway become relevant: not because the gateway “replaces” the cloud, but because it can sit between field equipment and cloud systems, helping collect, process, buffer, and forward data in a more controlled way.
A clean IoT diagram usually looks simple:
device → gateway → cloud → dashboard
Then the real site appears.
The network is not always stable. The data is not always clean. Some values repeat constantly. Some data is only useful when it changes. Some machines still speak older industrial protocols. Some assets are deployed in remote cabinets, energy sites, water stations, EV charging locations, or other places where sending someone on-site is expensive.
This is where the edge vs cloud discussion becomes less about competition and more about responsibility.
Edge and cloud are usually doing different jobs
Cloud computing is very good at things that need scale.
A cloud platform can collect data from many sites, store long-term records, run dashboards, support reports, integrate with business systems, and give remote teams a broader operational view.
Edge computing is useful closer to the equipment.
An edge gateway can collect selected data from field devices, handle local data processing, filter repeated values, buffer data during unstable network periods, and forward useful information upstream when the connection is available.
Those are not opposite roles.
A more realistic industrial IoT architecture is usually:
field devices → edge gateway → cloud platform → operations team
Each layer has a different job.
The edge gateway is usually better suited for local data collection, filtering, buffering, protocol handling, selected processing, and store-and-forward workflows.
The cloud platform is usually better suited for long-term storage, dashboards, remote monitoring, reporting, fleet-wide analysis, and application workflows.
The project team has to decide what data should stay local, what should be forwarded, and how the data path should behave when the site is not perfect.
The edge prepares the data.
The cloud organizes and uses the data.
The project team decides what should happen at each layer.That last part matters more than the architecture diagram.
The problem is not just “too much data”
Bandwidth reduction is one reason teams look at edge computing in IoT, especially when sites use cellular connectivity or operate in bandwidth-limited environments.
But the bigger issue is often not just data volume.
It is data usefulness.
A sensor may report the same value many times. A PLC may expose hundreds of registers, but only a few are relevant for remote monitoring. A water station may not need to send every raw reading immediately. A machine may generate operating values that matter locally but do not need to update a cloud dashboard every second.
Sending all raw data directly to the cloud can create a few problems:
●higher data traffic
●noisier dashboards
●more difficult troubleshooting
●unnecessary storage
●higher cellular data usage
●data gaps when the network is unstable
The system may be “connected,” but not necessarily well designed.
This is why IoT data filtering at the edge is useful. The goal is not to hide data. The goal is to send data that the cloud system and remote team can actually use.
What IoT data filtering can look like
Filtering at the edge can be very simple.
For example:
●If a sensor keeps reporting repeated readings, the gateway may send only meaningful changes or periodic summaries.
●If a machine produces status values, the gateway may forward operating states, alarms, or exceptions instead of every raw value.
●If a meter reports data regularly, the gateway may send scheduled readings or threshold-based events.
●If a PLC exposes many registers, the gateway may map only selected values into a cloud-friendly format.
●If a signal is high-frequency, the gateway may aggregate or reduce the data before cloud forwarding.
●If local equipment events occur, the gateway may prioritize alarms and state changes.
None of this sounds especially glamorous.
But in industrial IoT, the boring parts are often the important parts.
A gateway that filters, maps, buffers, and forwards data properly can make the cloud side much easier to work with. Dashboards become clearer. Alerts become more meaningful. Network traffic becomes more intentional.
This is one of the places where edge computing in IoT is practical rather than theoretical.
Store-and-forward matters when the network is not perfect
Many industrial IoT sites do not have perfect connectivity.
That is not a failure case. It is just reality.
Remote equipment rooms, utility cabinets, distributed energy assets, water infrastructure, EV charging sites, and cellular-connected machines may all experience network interruptions. Signal strength changes. Operator coverage varies. Antenna placement matters. Cabinets are not always in friendly locations.
In these environments, gateway data buffering and store-and-forward workflows become important.
A store-and-forward gateway usually works like this:
- collect selected field data
- store it locally if the network is unavailable
- forward it later when the connection returns
This can help reduce gaps in cloud monitoring data.
But it should not be oversold.
Store-and-forward does not magically guarantee that no data will ever be lost. The result depends on configuration, local storage, data volume, retry logic, network recovery time, timestamp handling, and how the cloud platform accepts delayed data.
Before using store-and-forward, teams should define things like:
●Which data should be buffered?
●How long should it be stored?
●What happens when the buffer is full?
●Should old data be overwritten or protected?
●How are timestamps preserved?
●Can the cloud platform handle delayed data correctly?
●How will the team know buffering happened?
These questions are more useful than simply asking whether a gateway supports buffering.
The feature matters.
The workflow matters more.Where an edge gateway fits
In an edge-to-cloud IoT workflow, the gateway is not just a pipe.
It is often the first place where field data becomes usable cloud data.
A practical workflow might look like this:
field device generates data
↓
gateway collects selected values
↓
gateway filters, maps, or processes data locally
↓
gateway buffers data if the network is unstable
↓
gateway forwards useful data to the cloud
↓
cloud platform stores, visualizes, and analyzes it
For readers who want to see how this kind of industrial edge gateway is packaged in a real product, the https://robustel.com/product/eg5120/ is a useful reference point.
The important thing is not the product page itself. The useful part is seeing how connectivity, edge data processing, industrial interfaces, and deployment needs come together in one gateway layer.
That is the part of the architecture that often gets underestimated.
When data should stay local
Local data processing is useful when it solves a specific problem.
It may make sense when data is:
●too frequent
●too repetitive
●too noisy
●too dependent on local context
●affected by unstable network links
●expensive to send continuously
●only useful after filtering or aggregation
For example, a gateway may send alarms instead of continuous machine values. It may forward state changes instead of every repeated reading. It may convert field data into a format the cloud platform can understand. It may buffer selected values during a cellular interruption.
But there is a risk here too.
Edge logic can become messy if nobody owns it.
Project teams should define what processing happens at the gateway, who maintains that logic, how it is tested, how updates are handled, and what happens if the local processing fails.
Edge processing should make the system easier to understand, not harder.
When data should go to the cloud
Cloud computing is still the right place for many things.
The cloud is usually better for:
●long-term data storage
●dashboards
●reports
●multi-site comparison
●trend analysis
●alert management
●business system integration
●remote access for operations teams
This is why “cloud vs edge computing” can be a misleading phrase.
Most mature IoT systems need both.
The edge is useful for preparing data near the site.
The cloud is useful for turning that data into operational visibility.The better question is not “edge or cloud?”
It is “which layer should do which job?”A few questions before sending industrial data to the cloud
Before forwarding industrial data to a cloud platform, I think teams should ask a few plain questions.
Start with the value of the data:
●Which values are actually useful to the cloud platform or remote team?
●Does every data point need to be sent?
●Would summaries, state changes, or alarms be enough?
Then look at the site conditions:
●What happens when the WAN or cellular link is interrupted?
●Is the site bandwidth-limited or cost-sensitive?
●Is the network stable enough for continuous cloud data forwarding?
Then define the buffering and cloud behavior:
●Which data should be stored temporarily?
●How long should it be stored?
●Can the cloud system handle delayed or filtered data?
●Will timestamps still make sense after delayed forwarding?
Finally, clarify ownership:
●Who owns the gateway logic?
●Who maintains the cloud integration?
●Who is responsible when the data path fails after deployment?
These questions help avoid a common mistake: collecting data before defining how it will be used.
That mistake is easy to make. The early prototype works. The dashboard looks good. Everyone agrees that more data is better.
Then the deployment scales, and the data path starts to matter much more.
Edge gateways do not replace the whole system
An edge gateway can support a stronger data workflow, but it does not replace everything else.
It does not replace PLCs.
It does not replace SCADA or MES.
It does not replace the cloud platform.
It does not remove the need for cybersecurity planning.
It does not automatically know which data is important.The gateway provides capability.
The project defines the result.
That distinction is important in edge computing vs cloud computing discussions. A gateway can collect, filter, process, buffer, and forward data, but the success of the architecture depends on site conditions, network quality, storage limits, application logic, cloud behavior, and long-term maintenance.
Closing thought
Edge computing vs cloud computing in IoT should not be treated as a winner-loser comparison.
In industrial IoT, edge computing is useful when data needs to be handled closer to the machine or site. Cloud computing is useful when data needs to be stored, visualized, analyzed, shared, and connected to wider systems.
A product such as Robustel EG5120 can support the site-side edge gateway layer in this kind of workflow, while Robustel’s device management tools can help teams keep gateway deployments visible and manageable over time.
But the practical goal is not to keep all data at the edge or send all data to the cloud.
The goal is to decide what should happen to industrial data before it travels.
That is where a lot of IoT architecture becomes real.
FAQ
Q1: What is the difference between edge computing and cloud computing in IoT?
Edge computing in IoT means handling selected data near the device, machine, gateway, or site where the data is generated. Cloud computing means sending data to a remote platform for storage, dashboards, analysis, reporting, and broader application workflows. In industrial IoT, edge and cloud are usually not competitors. Edge gateways prepare data, while cloud platforms organize and use it.
Q2: Does edge computing replace cloud computing?
Usually, no. Edge computing does not replace cloud computing in most industrial IoT systems. It changes what should happen before data reaches the cloud. The edge may filter, buffer, process, or convert data locally. The cloud may still handle long-term storage, dashboards, analytics, reporting, and integration across many sites.
Q3: Why does IoT data filtering matter?
IoT data filtering helps reduce unnecessary traffic and make cloud data more useful. Industrial sites may generate repeated sensor readings, PLC values, meter readings, machine states, and alarms. Not every raw value needs to be forwarded. Filtering at the edge can support bandwidth reduction, cleaner dashboards, and more meaningful cloud data forwarding.
Q4: What is a store-and-forward gateway?
A store-and-forward gateway temporarily stores selected data when the network link is unavailable and forwards it when connectivity returns. This is useful in unstable network IoT environments, such as remote sites, cellular-connected equipment, utility cabinets, water stations, energy assets, and EV charging sites. The final result depends on configuration, storage capacity, data volume, retry behavior, timestamp handling, and cloud-side support for delayed data.
Q5: Where does Robustel EG5120 fit in an edge vs cloud IoT architecture?
Robustel EG5120 fits into the site-side edge gateway layer. In an edge vs cloud IoT architecture, it can be used as the gateway between field equipment and remote platforms, supporting local data processing, edge data filtering, gateway data buffering, and cloud data forwarding depending on project configuration. It does not replace the cloud platform; it helps prepare industrial data before it is sent to the cloud.
Q6: When should industrial data be sent to the cloud?
Industrial data should be sent to the cloud when the value depends on storage, visibility, reporting, multi-site comparison, analytics, or integration with other applications. The cloud is usually where remote teams view data, compare sites, generate reports, and connect IoT data to business or maintenance workflows. The edge layer should help make that cloud data cleaner, more reliable, and easier to use.
I wrote this because edge vs cloud discussions can become a bit too abstract, while the real problems often show up in small decisions: what to filter, what to buffer, how to handle timestamps, when to retry, and who owns the gateway logic after deployment.
If you have worked with IoT systems, edge devices, cloud dashboards, or unreliable networks, I’d be curious to hear your experience.
Where does the data path usually get messy first in your projects? Is it the device protocol, the data format, the network, buffering, cloud integration, or the handoff between different teams?
Feel free to leave a question or share what you’ve seen in the comments. I’d be happy to compare notes.