← All Posts

July 10, 2026 · Architecture

The Industrial Edge Gateway Stack: What You Actually Need in 2026

The edge gateway market is bloated. Vendors sell "industrial IoT platforms" that require 4GB RAM, multiple services, and a Kubernetes cluster just to read Modbus registers and send data to the cloud. The actual requirements of an edge gateway are modest: protocol translation, local buffering, and northbound transport. Everything else is vendor bloat.

This guide cuts through the marketing and explains what an edge gateway actually does, the minimal stack that handles most use cases, and the over-engineered stack that vendors push. If you are designing edge infrastructure or evaluating gateway solutions, you need to understand the difference.

What an Edge Gateway Actually Does

An industrial edge gateway sits between field devices (PLCs, RTUs, sensors, drives) and upstream systems (cloud platforms, SCADA, historians). It performs four core functions:

Protocol Translation

Field devices speak OT protocols: Modbus RTU/TCP, BACnet/IP, Siemens S7, EtherNet/IP, OPC-UA. Cloud platforms and SCADA systems speak IT protocols: MQTT, HTTP, REST APIs. The edge gateway translates between them. It reads registers from Modbus devices, polls objects from BACnet devices, connects to S7 CPUs, and publishes the data via MQTT or HTTP.

This is not just format conversion. It includes:

  • Data type conversion: 16-bit Modbus registers to floats, BACnet Present-Value to JSON
  • Quality handling: Mapping BACnet Status-Flags or OPC-UA quality to Sparkplug B quality codes
  • Timestamping: Adding timestamps to data that lacks them (Modbus has no timestamps)
  • Tag mapping: Register 40001 becomes "boiler.outlet.temperature" in the northbound payload

Local Buffering

Networks fail. Cellular links drop. Cloud services go offline. The edge gateway must buffer data locally when connectivity is lost and transmit it when connectivity resumes. This is store-and-forward:

  1. Gateway reads data from field devices continuously.
  2. Gateway writes data to local storage (SQLite, file system, embedded database).
  3. Gateway attempts to transmit data to cloud/SCADA.
  4. If transmission fails, data remains in local storage.
  5. When connectivity resumes, gateway transmits buffered data.

Local buffering must handle hours or days of outage. A remote site with 100 sensors, reading every second, generates 8.64 million data points per day. The buffer must handle this without running out of storage or crashing.

Store-and-Forward

When connectivity returns, the gateway transmits buffered data. This is not just "send everything" — it requires:

  • Backpressure handling: If the cloud cannot ingest data fast enough, the gateway must throttle, not crash
  • Priority queues: Alarms transmit first, historical data transmits when bandwidth allows
  • Gap detection: If data is lost (disk corruption, buffer overflow), the gateway must log the gap
  • Ordering: Data should arrive at the cloud in timestamp order, not transmission order

Store-and-forward sounds simple, but robust implementation is complex. Many commercial gateways get this wrong.

Edge Compute

Edge compute means processing data locally instead of sending everything to the cloud. Typical edge compute tasks:

  • Filtering: Don't send data that hasn't changed (deadband filtering)
  • Aggregation: Calculate hourly averages from minute-level data
  • Alarm detection: Trigger local alerts when thresholds are exceeded
  • Simple analytics: Calculate efficiency, detect anomalies, run basic models

Edge compute reduces bandwidth usage, improves responsiveness (local alarms don't depend on cloud latency), and provides offline capability. But most edge deployments only need basic filtering and alarm detection — not heavy analytics.

The Minimal Stack: Three Components

The minimal edge gateway stack consists of three components. This stack handles 80% of industrial use cases, runs on 512MB RAM, and fits on a Raspberry Pi.

Component 1: Protocol-Capable Agent

A single agent that:

  • Speaks field protocols (Modbus TCP/RTU, BACnet/IP, S7, EtherNet/IP, OPC-UA)
  • Speaks northbound protocol (MQTT, HTTP, or both)
  • Handles tag mapping and data type conversion
  • Performs basic edge compute (filtering, alarms)
  • Manages local buffering

This agent is a single process. It polls devices, buffers data, and transmits to the cloud. No separate services. No containers. No orchestration.

Component 2: Local Store

A local database or file system for buffering data during connectivity outages:

  • SQLite: Embedded database, no separate service, handles millions of records, runs on 128MB RAM
  • TimeSeriesDB: Specialized for time-series data, efficient compression, but heavier than SQLite
  • File-based logging: CSV or line-delimited JSON, simple but no indexing or compression

SQLite is sufficient for most edge gateways. It handles write-heavy workloads, requires no configuration, and is included in the agent binary (no separate installation).

Component 3: Northbound Transport

The mechanism for sending data to the cloud or SCADA:

  • MQTT Explorer: Publishes data to an MQTT broker (cloud-hosted or on-premise)
  • HTTP Client: POSTs data to REST APIs or cloud services
  • OPC-UA Server: Exposes data as an OPC-UA server for SCADA clients

Most edge gateways use MQTT because it supports QoS levels (exactly-once delivery), retains connection state, and works well over unstable networks. HTTP is simpler but lacks QoS and requires more bandwidth.

The minimal stack is a single binary. The protocol agent, local store, and northbound transport are compiled into one executable. Deployment is copying the binary to the device. Configuration is a single file. Updates are replacing the binary. This is how Voltrus SCADA works.

The Over-Engineered Stack: Vendor Bloat

The over-engineered stack is what vendors sell. It includes unnecessary components that bloat resource requirements and increase complexity. A typical over-engineered stack:

MQTT Broker (Even When Not Needed)

The stack includes Mosquitto, EMQX, or HiveMQ even when the gateway only publishes to a cloud broker. The local broker is unnecessary — the agent can connect directly to the cloud broker. But vendors include a local broker because:

  • They want to support local MQTT subscribers (rare in practice)
  • They use MQTT for internal service communication (microservices architecture)
  • It looks impressive in the feature list

Resource cost: 20MB RAM for Mosquitto, 100MB+ for EMQX.

Flow Engine (Node-RED)

The stack includes Node-RED for visual logic development. Node-RED is excellent for prototyping, but in production edge gateways:

  • Most logic is simple (if temperature > threshold, send alarm) — a few lines of code suffice
  • Node-RED flows are hard to version control and test
  • Node-RED requires a browser-based IDE — not ideal for headless edge devices
  • Node-RED adds attack surface (remote code execution risk)

Resource cost: 200MB+ RAM for Node-RED.

Time-Series Database (InfluxDB, TimescaleDB)

The stack includes a TSDB even when SQLite is sufficient. TSDBs are optimized for time-series data, but they are heavy:

  • InfluxDB: 500MB+ RAM, separate service, complex configuration
  • TimescaleDB: Requires PostgreSQL (100MB+ RAM), plus TimescaleDB overhead

SQLite handles time-series data for most edge gateways. Only use a TSDB if you need:

  • Complex downsampling and rollups (SQL can handle basic cases)
  • High-performance queries over millions of records (most edge gateways transmit, not query)
  • Compression to fit months of data on limited storage (edge gateways typically buffer hours/days, not months)

Visual Dashboard (Grafana)

The stack includes Grafana for local visualization. Most edge gateways are headless (no local HMI). When visualization is needed:

  • Local operators view SCADA/HMI screens, not Grafana dashboards
  • Remote users view cloud dashboards, not edge-local dashboards
  • Grafana adds no value if the gateway's job is data transport, not visualization

Resource cost: 200MB+ RAM for Grafana.

The Total Cost

Add it up:

  • Mosquitto: 20MB
  • Node-RED: 200MB
  • InfluxDB: 500MB
  • Grafana: 200MB
  • Total: 920MB+ RAM minimum

This is why vendors require 2GB or 4GB RAM devices. The protocol agent uses 50MB. The other 870MB+ is bloat.

Each component adds failure modes. More services mean more logs, more monitoring, more potential crashes. When the edge gateway fails, is it the protocol agent? The broker? The database? The dashboard? Troubleshooting a multi-component stack on a remote device is painful.

Minimal Stack vs Over-Engineered Stack

Aspect
Minimal Stack
Over-Engineered Stack
Winner
RAM Usage
256-512 MB
2-4 GB
Minimal
Deployment
Single binary
Multiple services
Minimal
Configuration
One config file
Multiple configs
Minimal
Updates
Replace binary
Update each service
Minimal
Monitoring
One process
Multiple processes
Minimal
Flexibility
Protocol + transport only
Visual development, local dashboard
Over-Engineered
Local HMI
None (use SCADA)
Grafana dashboard
Over-Engineered
Hardware Cost
Raspberry Pi Zero ($10)
Industrial PC ($500+)
Minimal
Complexity
Low
High
Minimal
Attack Surface
Small
Large (more services)
Minimal
Failure Isolation
Process restart
Which service failed?
Minimal
Learning Curve
Shallow
Steep
Minimal

The pattern is clear. The minimal stack wins on resource usage, simplicity, and operational complexity. The over-engineered stack wins only when you need local visualization, multi-tenant data ingestion, or visual development. For most edge use cases, these are not requirements.

When to Use Each Stack

Use the Minimal Stack When:

  • Remote sites: Cellular-connected gateways, solar-powered installations, locations with limited IT support
  • Resource-constrained hardware: Raspberry Pi, industrial gateways with 512MB RAM, embedded systems
  • Simple protocol translation: Modbus → MQTT, BACnet → HTTP, no complex processing
  • Cost-sensitive deployments: Hardware cost matters, per-site license costs matter
  • High-volume deployments: Hundreds or thousands of gateways — operational complexity scales
  • Headless operation: No local HMI, no local visualization needed

Use the Over-Engineered Stack When:

  • Local HMI required: Operators need local visualization and control independent of cloud/SCADA
  • Multi-tenant data ingestion: Gateway accepts connections from multiple external systems (not just one cloud/SCADA)
  • Complex edge analytics: Running machine learning models, complex aggregations, or rule engines that exceed simple filtering
  • Visual development: Non-programmers need to configure logic and integrations without coding
  • Local data historian: Storing months or years of data locally (not just buffering for outages)
  • Protocol bridging: Gateway acts as a protocol bridge between multiple local systems (PLC to PLC, not PLC to cloud)

Be honest about your requirements. Most edge deployments need protocol translation and buffering. They do not need local Grafana dashboards or Node-RED flows. The over-engineered stack is justified only when you have specific requirements that the minimal stack cannot meet.

The default choice should be the minimal stack. Only choose the over-engineered stack if you have a specific requirement that demands it. The minimal stack is simpler, cheaper, more reliable, and easier to operate.

How Voltrus SCADA Implements the Minimal Stack

Voltrus SCADA is a single binary that implements the minimal edge gateway stack:

Protocol-Capable Agent

Voltrus includes drivers for Modbus TCP/RTU, BACnet/IP, and Siemens S7. It reads data from these devices and handles tag mapping, data type conversion, and quality mapping internally. No separate connectors or plugins required.

Local Store

Voltrus uses SQLite for local buffering. Data is written to SQLite as it is read from devices. When cloud connectivity is lost, data continues buffering. When connectivity resumes, Voltrus transmits buffered data via MQTT or HTTP.

Northbound Transport

Voltrus speaks MQTT (including Sparkplug B) and HTTP. It can publish to cloud brokers (AWS IoT Core, Azure IoT Hub) or on-premise brokers (Mosquitto, EMQX). It can POST data to REST APIs or cloud services. It can also expose data as an OPC-UA server for SCADA clients.

Edge Compute

Voltrus includes basic edge compute: deadband filtering (don't send unchanged values), alarm detection (thresholds, rate-of-change), and simple aggregation (hourly/daily min/max/average). This covers most edge use cases without requiring Node-RED or external rule engines.

Resource Requirements

Voltrus runs on 256MB RAM. It fits on a Raspberry Pi Zero. It starts in seconds. It has a small attack surface (single binary, minimal dependencies). Updates are replacing the binary.

Pricing

Voltrus costs $249 for a lifetime license. No per-device fees. No annual renewal. No subscription. For a deployment of 100 gateways, that is $2.49 per gateway. Compare to commercial edge platforms that charge $50-$500 per gateway annually.

Voltrus is the minimal stack, production-ready. It replaces the multi-component vendor stack with a single binary. It runs on smaller hardware, costs less to license, and is simpler to operate. If your edge gateway needs are protocol translation and buffering, Voltrus handles it without the bloat.

Frequently Asked Questions

What does an industrial edge gateway actually do?

An industrial edge gateway performs protocol translation (converting Modbus, BACnet, S7, and other field protocols to MQTT, OPC-UA, or cloud APIs), local buffering (storing data when cloud connectivity is lost), store-and-forward (buffered data is transmitted when connectivity resumes), and edge compute (processing data locally: filtering, aggregation, alarm detection, basic analytics). The gateway sits between field devices and cloud/SCADA systems, bridging the gap between OT protocols and IT infrastructure.

What is the minimal edge gateway stack?

The minimal edge gateway stack consists of three components: one protocol-capable agent that speaks field protocols (Modbus, BACnet, S7) and a northbound protocol (MQTT, HTTP), one local store for buffering data during connectivity outages (SQLite or TimeSeriesDB), and one northbound transport for sending data to the cloud or SCADA system. This minimal stack runs on 512MB RAM, fits on a Raspberry Pi, and handles most industrial use cases.

Why do modern edge stacks require 4GB RAM?

Modern edge stacks require 4GB+ RAM because they include unnecessary components: a separate MQTT broker (Mosquitto/EMQX) even when the gateway only publishes, a flow engine (Node-RED) even when logic is simple, a time-series database (InfluxDB/TimescaleDB) even when SQLite is sufficient, and a visual dashboard (Grafana) even when the gateway is headless. Each component adds overhead. Mosquitto (20MB), Node-RED (200MB+), InfluxDB (500MB+), Grafana (200MB+) — the stack bloat is real.

How does Voltrus SCADA compare to traditional edge gateway stacks?

Voltrus SCADA is a single binary that replaces the multi-component edge gateway stack. It includes protocol drivers (Modbus, BACnet, S7), data logging (SQLite-based buffering), northbound transport (MQTT, HTTP), and a built-in web interface. Voltrus runs on 256MB RAM, fits on a Raspberry Pi Zero, and provides the same functionality as a broker + flow engine + TSDB + dashboard stack, but with 10x less resource usage and simpler deployment.

When should you use a full edge gateway stack vs minimal stack?

Use a full stack (broker + flow engine + TSDB + dashboard) when you need local HMIs, multi-tenant data ingestion, complex edge analytics, or visual development. Use a minimal stack (single binary gateway) for remote sites, resource-constrained hardware, simple protocol translation, and cost-sensitive deployments. Most edge use cases are served by the minimal stack. The full stack is over-engineering for most applications.

Deploy the Minimal Edge Stack

Voltrus SCADA implements the minimal edge gateway stack in a single binary. Modbus, BACnet, S7 drivers. SQLite buffering. MQTT and HTTP northbound transport. Edge compute with filtering and alarms. Runs on 256MB RAM. $249 lifetime license.

Explore Voltrus SCADA

Further Reading