Historian federation is the practice of querying many separate process historians as if they were one, without physically consolidating all their data into a single store. Each site keeps its own historian, and a federation layer routes a query to the relevant historians, gathers their partial answers, and stitches them into one result. The goal is fleet-wide visibility across plants, regions, or wellfields while letting each location retain and own its own time-series data.
Historian Federation in one line: Historian federation is an architecture that lets a single query span multiple distributed historians without copying all their data into one central database. A federation layer distributes the query, collects results from each site historian, and merges them, so a user gets fleet-wide answers while the data stays where it was recorded.
The alternative to federation is consolidation: copy every tag from every site into one giant historian. Consolidation is conceptually simple but expensive and fragile at scale. It moves enormous volumes of time-series data over the network, duplicates storage, and creates a single point that must ingest everything reliably. For a company with dozens of sites on constrained links, continuously shipping all raw data to one place is often impractical.
Federation flips the model. Instead of moving the data to the query, it moves the query to the data. When a user asks for a value across the fleet, the federation layer fans the request out to each participating historian, each of which answers only for its own tags, and the layer assembles the responses. Most data never leaves its home historian; only the query and its results travel. This keeps bandwidth low and lets each site continue operating even if the central layer is unavailable.
The tradeoff is that a federated query is only as fast and available as its slowest or least reachable member. If one site is offline, the federation layer must decide whether to return a partial result or wait. Federation trades the storage and bandwidth cost of consolidation for the coordination cost of querying many systems at once.
For a federated query to make sense, tags must be uniquely identifiable across sites. Two plants might both have a tag literally named FlowRate, so federation depends on a namespacing scheme, often a site or asset prefix, that keeps them distinct. A clean, hierarchical naming convention is what lets a user ask for the same measurement across every site and get an unambiguous, comparable answer.
Latency is the other central concern. Because a federated query touches multiple remote systems, its response time is governed by the slowest responder, and network conditions to a remote field site can be poor. Practical federation layers often set per-source timeouts, cache recent results, and return clearly labeled partial results rather than hanging indefinitely. Users need to know when an answer covers the whole fleet and when one site was unreachable.
It helps to distinguish federation from two neighbors. Tiered retention is about how long and at what resolution a single historian keeps data, not about spanning multiple historians. Simple replication copies one historian's data to another for backup or reporting, which is consolidation by another name. Federation is specifically the ability to query across independent stores in place, presenting a virtual, unified view without a physical merge.
Historian federation fits naturally with cloud SCADA over widely dispersed operations. Each field site or plant runs its own local historian, sized for its own tags and retention, while the cloud platform acts as the federation point that spans them. An engineer running a fleet-wide report asks the platform, which resolves the query against the relevant site historians and returns a combined answer, without every site's raw data ever being centralized.
For oil and gas this pattern matches the geography. Wellfields, gathering systems, and terminals are scattered across regions and connected by variable links, and shipping every raw sample to one database is costly. Federation lets the business ask questions like total production across a basin, or downtime by region, while each site keeps its high-resolution data locally and answers only for itself when queried.
As cloud SCADA for oil and gas and other industries, Merobix is positioned to serve as that federation point across distributed sites. Site historians retain their own data and namespacing keeps tags distinct, while the platform gives operators a single place to run cross-site queries. The result is fleet-wide reporting without the cost and fragility of forcing every reading into one monolithic store.
Replication copies data from site historians into a central store, which is consolidation by another name and carries its bandwidth and storage cost. Federation leaves the data where it was recorded and instead sends the query out to each historian, merging the answers. Most data never moves; only the query and its results travel.
The federation layer must decide how to handle it, usually by applying a per-source timeout and returning a clearly labeled partial result rather than hanging. That is why federated queries need good status reporting, so users know whether an answer covered the whole fleet or excluded an unreachable site.
They need tags that are uniquely identifiable across sites, which usually means a namespacing scheme such as a site or asset prefix. Two plants can each have a tag called FlowRate as long as the naming convention keeps them distinct, so a cross-site query returns unambiguous, comparable results.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.