A factory floor has 10,000 sensors each sending readings every second. Sending all 10,000 readings per second to the cloud costs bandwidth money and creates a massive ingestion problem. Most readings are uninteresting: the temperature was 23.4C last second, it’s 23.4C this second. Edge processing filters, aggregates, and transforms data before it reaches the cloud, pushing computation closer to where data originates.

What to Do at the Edge#

Filtering: only forward readings that cross a threshold or change by more than a delta. A temperature sensor that changes by less than 0.5C since the last reading sends nothing. Only anomalies and significant changes reach the cloud. This alone can reduce data volume by 80-90% for stable industrial environments.

Aggregation: instead of sending 60 individual readings per minute, compute min/max/average over the minute and send one record. Sufficient for trend analysis; individual readings are discarded.

Anomaly detection: run a simple model (threshold rule, moving average deviation) on the edge device or gateway. If the model fires, send the raw readings for the anomaly window along with the alert. Normal readings remain aggregated.

graph TD A[10000 sensors: raw readings every 1s] --> B[Edge gateway: filter and aggregate] B --> C{Reading changed by more than 0.5C?} C --> |No| D[Discard: 80% of readings never leave the factory] C --> |Yes| E[Forward to cloud: MQTT publish] B --> F[Compute 1-minute aggregates: min, max, avg] F --> G[Publish aggregate: 1 record per sensor per minute] E --> H[Cloud: time-series ingestion] G --> H style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style H fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

Edge Gateway vs Edge Device#

Edge processing happens at two levels:

On the device itself: microcontrollers with processing capability can filter locally. A Raspberry Pi-class device can run a Python process doing threshold checks. A simple 8-bit microcontroller cannot.

On an edge gateway: a local server (often an industrial PC or ruggedized box) aggregates from many constrained sensors, runs the processing, and connects to the cloud. Sensors connect to the gateway via local protocols (Modbus, BACnet, Zigbee); the gateway speaks MQTT to the cloud. This is the common industrial IoT pattern.

Offline Resilience#

The cloud connection goes down. The edge gateway must buffer locally and replay when connectivity restores. Buffer to local disk: SQLite, a flat file, or a local message queue. Bounded buffer: if offline for more than 24 hours, start dropping oldest readings to make room for new ones. Alert on prolonged offline status via a separate heartbeat channel.

At Oracle#

Oracle IoT Cloud was deployed in manufacturing customers with 5,000-50,000 sensors per facility. Without edge processing, the raw data volume exceeded what cellular uplinks could handle during peak production. Edge gateways ran a rule engine that customers configured: “only forward if value differs from last forwarded by X%.” One automotive customer reduced their cellular data costs by 73% after deploying edge filtering. The cloud ingestion pipeline remained unchanged; the edge layer was additive.

What I’m Learning#

Edge processing is about pushing decisions closer to where data lives. The right split: real-time responses (safety shutoffs, local alarms) run on the edge where latency is zero. Trend analysis, historical queries, and cross-facility comparisons run in the cloud where compute and storage scale freely.

Have you worked on IoT or edge deployments, and where did the edge-vs-cloud split end up being in your system?