Cloud vs Edge Historian Placement: Where Should Data Live?
Deciding where your time-series data lives, on a box at the site or in a central cloud store, shapes what you can query, what survives a network cut, and what you pay to move data around. This page compares edge and cloud historian placement as a design decision for a controls engineer, and explains why the honest answer for most distributed operations is a hybrid that keeps a buffer at the edge and the system of record in the cloud.
Cloud vs edge historian placement in one line: An edge historian stores data at the site, so a network outage never loses samples and local queries are fast, but each site's history is siloed. A cloud historian centralizes every site's data for fleet-wide queries and long retention, but depends on the uplink and can lose data during an outage unless the edge buffers. The robust design is usually hybrid: buffer at the edge, keep the system of record in the cloud.
Decide by Outage Behavior and Query Scope
Two questions decide placement more than any other. First, what happens to your data when the link to the site drops? An edge historian keeps recording locally regardless of the network, so no samples are lost; the classic implementation is an edge historian ring buffer that holds data until the uplink returns. A cloud-only historian records nothing during an outage unless something at the edge buffers on its behalf, which is why pure cloud placement without an edge buffer is fragile for remote sites on cellular or satellite links.
Second, what do you need to query? If the questions are local, this site's last shift, this pump's trend, an edge historian answers them quickly without touching the WAN. If the questions are fleet-wide, compare this metric across forty sites, roll up production for the region, then the data must be centralized, and a cloud historian or a federation layer is doing the work. A design that stores only at the edge makes cross-site analysis painful; a design that stores only in the cloud makes every local query depend on a healthy uplink.
Compare Edge and Cloud Placement
The table lines up the placements against the factors that actually decide the design, with the hybrid shown because it is the answer most distributed fleets land on.
| Factor | Edge historian | Cloud historian | Hybrid |
|---|---|---|---|
| Data survives link outage | Yes - records locally | No, unless edge buffers | Yes - edge buffers then syncs |
| Local queries | Fast, no WAN needed | Depend on uplink | Fast at edge, full history in cloud |
| Fleet-wide queries | Hard - siloed per site | Native | Native in the cloud tier |
| Long retention | Limited by local disk | Scales centrally | Short at edge, long in cloud |
| Bandwidth use | Low - stays local | Continuous upload | Batched sync, backfill after outage |
| Single point of loss | The local box | The uplink | Mitigated on both ends |
The hybrid is not a compromise so much as a division of labor. The edge holds a rolling buffer sized to ride out the longest credible outage and answers local queries; the cloud is the durable system of record that every site feeds and that fleet-wide analysis runs against. When a link returns, the edge performs a historian backfill so the cloud record has no gap.
Federation is the alternative to physically moving all data to one place. A historian federation lets a central query reach across multiple historians as if they were one, which suits operations that want fleet-wide queries but must keep each site's data resident locally for sovereignty, bandwidth, or policy reasons. Federation trades slower cross-site queries for not having to centralize the raw data.
When Each Placement Wins
Pure edge placement wins for isolated sites with poor connectivity where nobody needs cross-site queries and long central retention is not required. A single remote facility that is monitored locally and only occasionally pulled up centrally can live entirely on an edge historian, with backups the only reason its data ever leaves the box.
Pure cloud placement wins when connectivity is reliable and the value is in the aggregate. Well-connected sites, or a control room consolidating many facilities, benefit from every sample landing in one queryable store, provided there is enough edge buffering to survive the outages that will still happen. The mistake is going cloud-only with no edge buffer on links that drop, which quietly punches holes in the record.
The hybrid wins for the common case: a fleet of remote sites on imperfect links that must not lose data and whose value comes from both local operation and fleet-wide analysis. This is the setting a cloud-native platform such as Merobix is built around, keeping a buffer at each site so an outage never loses samples while the central store holds the durable, queryable history the whole operation shares.
Pitfalls in Historian Placement
The most common and most damaging pitfall is cloud-only placement with no edge buffer on unreliable links. It works flawlessly in the demo, then loses every sample during the first real cellular outage, and the gaps are invisible until someone needs the data that was never recorded. Any remote site whose uplink can drop needs a buffer at the edge regardless of where the system of record lives.
A second trap is undersizing the edge buffer for the worst credible outage. A buffer that holds an hour is worthless against a day-long link failure, so size it against the longest outage you must survive plus margin, and monitor how full it gets. The final pitfall is siloing everything at the edge and then discovering, months later, that fleet-wide analysis is nearly impossible because no central store was ever built. Decide the query scope up front; retrofitting centralization onto forty isolated historians is far more work than planning the cloud tier from the start.
Frequently Asked Questions
Should my historian be at the edge or in the cloud?
For a single isolated site with poor connectivity and no need for cross-site queries, an edge historian alone is fine. For a fleet whose value comes from fleet-wide analysis and long retention, you need a central cloud store, but on any link that can drop you must keep an edge buffer so an outage does not punch holes in the record. Most distributed operations land on a hybrid: buffer at the edge, system of record in the cloud.
Does a cloud historian lose data during a network outage?
It does if nothing at the edge is buffering on its behalf, because a pure cloud store records only what reaches it. That is why cloud-only placement is fragile on cellular or satellite links that drop. The fix is an edge buffer or ring that keeps recording locally through the outage and backfills the cloud when the link returns, so the central record ends up complete despite the interruption.
What is historian federation and when do I use it?
Federation lets a central query reach across several historians at once as if they were a single store, without physically moving all the raw data to one place. Use it when you want fleet-wide queries but must keep each site's data resident locally for bandwidth, sovereignty, or policy reasons. The trade is slower cross-site queries compared with a single centralized store, in exchange for not having to centralize the underlying data.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.