Home Time-series basics Data Center & Infrastructure Telemetry Postgres basics Postgres guides Postgres best practices Postgres extensions

Plant Historian: What It Captures and Where the Analytics Layer Begins

By Tiger Data Team

Updated at Jul 17, 2026

What Is a Plant Historian?

A plant historian is software built to continuously capture and store time-stamped process and machine data, temperatures, pressures, cycle counts, machine states, coming off PLCs, SCADA systems, and sensors on a factory floor. It's optimized for two things most general-purpose databases aren't built for out of the box: sustained high-frequency writes and fast retrieval of long-term trends. If you've run into the broader term "data historian," this is the same underlying technology. "Plant historian" is the flavor of it that shows up in discrete manufacturing, next to OEE, downtime, and quality conversations, rather than the continuous-process, oil-and-gas framing covered in what is a data historian.

We should say upfront where we're coming from: Tiger Data sells a database. This guide is a conceptual primer on what a plant historian does and where its job ends, not a product comparison. If you're evaluating a specific historian (such as Proficy, PI, FactoryTalk, dataPARC), this page won't rank them against each other.

One common misconception worth naming directly: a plant historian and OEE or MES software often get talked about as if they're the same category. At least one vendor sells a product literally named "Plant Historian OEE Software," and CMMS-adjacent vendors have written about the two being conflated in buyer conversations. They aren't the same thing. A historian stores raw data. OEE is a number computed from that data. The rest of this page draws that line, and hands off where the line gets crossed.

What a Plant Historian Actually Captures

A historian's native job is narrow, and it does it well: continuous, timestamped raw values per tag, one row per reading per point, temperature, pressure, current draw, cycle count. Most historians compress at the point of capture using exception or deadband-style algorithms, so only value changes that cross a threshold get written to disk, not every scan cycle. That's a genuine strength, not a footnote. The OT protocol connectors that ship with a historian (OPC UA, Modbus, proprietary PLC drivers) are difficult to replicate, and most general-purpose databases don't ship with them at all.

Model that native job as two tables. A uns_namespace table maps the tag hierarchy. This illustrative example reuses the pattern already established in Tiger Data's Ask Your Factory Floor Anything and Unified Namespace content, using a fictional company, ACME Manufacturing:

CREATE TABLE uns_namespace (
    id              INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    enterprise      TEXT NOT NULL,
    site            TEXT NOT NULL,
    area            TEXT NOT NULL,
    line            TEXT NOT NULL,
    cell            TEXT NOT NULL,
    tag_name        TEXT NOT NULL,
    uns_path        TEXT GENERATED ALWAYS AS (
                        enterprise || '/' || site || '/' || area || '/' || line || '/' || cell || '/' || tag_name
                    ) STORED,
    UNIQUE (enterprise, site, area, line, cell, tag_name)
);

Alongside it, a tag_history hypertable stores the raw readings, one row per tag per timestamp:

CREATE TABLE tag_history (
 ts TIMESTAMPTZ NOT NULL,
 tag_id INT NOT NULL REFERENCES uns_namespace (id),
 value DOUBLE PRECISION NOT NULL,
 quality_code SMALLINT DEFAULT 0
) WITH (
 tsdb.hypertable,
 tsdb.partition_column = 'ts',
 tsdb.chunk_interval = '1 day'
);

That's what a historian natively captures: what a sensor reported, when, and (via quality_code) how much to trust the reading. What does not natively live in this layer, by design, is anything computed on top of the raw signal: OEE, downtime-state classification, quality-and-production joins. Those live in a different layer, covered next.

Where the Historian Layer Ends and the Analytics Layer Begins

This is the boundary. Raw tag history answers one question: what value did this sensor report, and when. OEE, downtime duration, and quality reporting all answer a different kind of question, one that requires computing something on top of the raw data. The result is a derived layer, not a stored one, and it's the distinction the rest of this page is built around.

Historians aren't blind to rollups; most ship some charting capability of their own. Here's a compact, historian-native example: an hourly average per tag, the kind of trend rollup a historian client displays on a chart. Using the tag_history hypertable above, a continuous aggregate computes it directly in Postgres:

CREATE MATERIALIZED VIEW tag_hourly
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 hour', ts) AS bucket,
    tag_id,
    avg(value) AS avg_value,
    min(value) AS min_value,
    max(value) AS max_value
FROM tag_history
GROUP BY bucket, tag_id;

Resolve it back against the namespace and you get a trend a shift supervisor can actually read, temperature for a specific press, by hour, without opening a second tool:

SELECT r.bucket, ns.tag_name, r.avg_value, r.min_value, r.max_value
FROM tag_hourly r
JOIN uns_namespace ns ON ns.id = r.tag_id
WHERE ns.site = 'detroit' AND ns.tag_name = 'temperature_c'
ORDER BY r.bucket;

This, too, is a real capability: hypertables and continuous aggregates hold and query this layer directly, in Postgres, with standard SQL. But it's still a rollup of raw values. It is not OEE by shift, it is not downtime-state duration, and it is not a quality-and-production join. Those require modeling machine-state transitions and joining production counts against quality events, a different schema shape than the one above. Tiger Data's Manufacturing Analytics Database guide covers that full build-out, with the OEE, downtime, and quality schema and SQL patterns. This page won't re-derive it here.

What's differentiated isn't the rollup query itself. It's that the same database holding the raw tag history can also hold the derived analytics layer. Traditionally, that's two systems: a historian for capture, and a separate analytics tool or BI layer for the OEE math. On Postgres, it's one database, queried with SQL you already know.

Teams building manufacturing analytics platforms on Postgres and TimescaleDB use this same underlying pattern in production. United Manufacturing Hub's open-source stack and Takton's Sense machine-monitoring platform (which streams raw machine power and vibration telemetry alongside machine-state events into Tiger Cloud) are two examples. This is directional validation that the pattern holds up outside a single vendor's marketing, not a claim that either runs the exact schema shown here.

Plant Historian vs. OEE Software vs. Manufacturing Analytics Database

	Plant historian (PI, Proficy, dataPARC, FactoryTalk)	OEE/MES software (Guidewheel, Tractian, TeepTrak-style tools)	Manufacturing analytics database (Tiger Data’s TimescaleDB)
What it is	Purpose-built store for raw OT tag data, with native protocol connectors	Application layer that computes and displays OEE, downtime, and work-order data	SQL-native database that stores raw tag history and the derived analytics layer together
Primary buyer	Controls/automation engineering	Operations/plant management	Data/platform engineering
Query interface	Vendor-specific client, some SQL bridges	Dashboard/app, not a query interface	SQL
Best-fit use case	Brownfield sites standardized on OPC UA, Modbus, or proprietary PLC drivers	Teams that want an out-of-the-box OEE dashboard and work-order workflow	Teams building custom analytics, dashboards, or AI-agent access on top of factory data
Strengths	Native OT connectivity most databases don't ship with; decades of industrial protocol integration	Fast time-to-dashboard, no custom SQL required	One system for raw and derived data; standard SQL; joins against ERP and quality data
Limitations	Limited SQL-native querying and joins against relational business data	Not a data-capture layer; depends on a historian, or its own ingestion, for raw tag data	Not a substitute for native OT protocol connectors in a brownfield plant; not an out-of-the-box OEE dashboard

None of these three replace each other outright. For the fuller keep, replace, or run-parallel discussion specific to historians and time-series databases, see data historian vs. time-series database.

Decision Framework: Do You Still Need a Separate Historian?

Keep your existing historian if: you're in a brownfield plant with deep investment in OT protocol connectors, and you don't yet need SQL-native querying or to feed factory data into other tools like BI dashboards or AI agents.

Run the historian and a database in parallel if: you need the historian's native OT connectivity for ingestion, but you also want SQL-native access to the same data for reporting, dashboards, or newer tooling the historian vendor doesn't support well.

Consolidate onto a manufacturing analytics database if: you're already exporting historian data into spreadsheets or a separate BI layer to do OEE, downtime, or quality analysis the historian itself doesn't do. That's a sign the analytics layer, not the historian, is your actual bottleneck.

Stay with a purpose-built OEE or MES tool if: your primary need is an out-of-the-box dashboard and work-order workflow, not custom analytics or SQL access to the underlying data.

How Historian Data Actually Gets Collected in Mixed-Vintage Plants

Ingestion, not database choice, is often the harder problem. Most factory floors run a mix of decades-old PLCs and newer sensors, and getting clean tag data out of legacy equipment is a real challenge that no database decision solves on its own.

Directionally, a wave of retrofit sensor approaches that avoid touching legacy PLC controls has emerged for exactly this reason. Vendors in this space report high accuracy without modifying existing controls. Treat that as an industry trend worth watching, not a Tiger Data claim.

Be clear-eyed about what choosing Tiger Data’s TimescaleDB as the analytics or historian-layer database does and doesn't solve. It doesn't solve OT connectivity by itself. Whatever database ends up underneath, you still need an ingestion path, OPC UA, MQTT, or a vendor connector, into it. For the ingestion side of this problem, see connecting MQTT to PostgreSQL and edge database patterns for factory devices.

Getting data in is a separate question from whether a historian-only setup still fits once it's in. That's the question the rest of this page turns to.

Migration Paths

Teams tend to outgrow a historian-only setup along one of three paths.

From a legacy historian, when SQL-native querying or AI-agent access over factory data becomes necessary. See SCADA data management at scale for the fuller migration patterns.

From spreadsheet-based OEE tracking exported out of the historian, once manual calculation stops scaling with more lines or shifts.

From a generic time-series database, when relational joins against production or quality data become necessary and a time-series-only store doesn't have a natural home for that relational business data.

For the complete walkthrough of each path, including schema and query specifics, see the migration paths section of the Manufacturing Analytics Database guide.

Where to Go Deeper

If you need the complete OEE, downtime, and quality-and-production schema and SQL patterns, the Manufacturing Analytics Database guide is the next page to read. It picks up exactly where this one leaves off: the derived analytics layer, modeled and queried in full.

Tiger Data’s TimescaleDB covers this same industrial telemetry pattern, raw capture plus a derived analytics layer on one database, in other verticals too, including data center infrastructure and fleet telemetry, if you work across multiple industrial domains.

FAQ

What is a plant historian?

Software that continuously captures and stores time-stamped machine and process data from PLCs, SCADA systems, and sensors on a factory floor, built for high-frequency writes and long-term trend retrieval.

What's the difference between a plant historian and a data historian?

They're the same underlying technology. "Plant historian" typically refers to the discrete-manufacturing, factory-floor flavor, while "data historian" is used more broadly, including continuous-process industries like oil and gas.

What's the difference between a plant historian and OEE software?

A historian stores raw tag data. OEE software, or the OEE calculation itself, is a derived metric computed from that data: availability times performance times quality. The two get conflated often, but they're different layers, not competing products.

Do I still need a plant historian if I already have an MES or OEE platform?

Often, yes, for the underlying raw data capture. Most MES and OEE platforms consume historian data rather than replacing the historian's ingestion and storage role.

What database technology do plant historians typically run on?

Historically, proprietary time-series stores built into vendor products like PI, Proficy, and dataPARC. Increasingly, teams are also storing this data directly in general-purpose databases with time-series extensions, like Postgres with hypertables.

Can you calculate OEE directly from raw historian tag data?

Yes. OEE is computed from raw cycle-count, downtime-state, and quality-event data rather than stored as a native historian field.

How long should historian or production data be retained?

It depends on the use case: recent high-frequency data serves real-time dashboards, while downsampled or compressed data supports longer-term trend analysis. Columnstore compression is the mechanism that keeps years of history queryable without the storage cost of raw retention.

Can PostgreSQL replace a plant historian like AVEVA PI System or AVEVA Historian?

Directionally, Postgres with time-series extensions can absorb a growing share of historian functionality, SQL-native storage and querying of tag data, but historians retain native OT protocol connectors that many brownfield plants still depend on.

What's the difference between a plant historian and a manufacturing analytics database?

A historian captures and stores raw tag data. A manufacturing analytics database also models and computes OEE, downtime, and quality metrics from that data, often in the same underlying database.

How is machine downtime tracked differently in a historian versus an analytics layer?

A historian records raw machine-state signals as they change. Deriving actual downtime duration and cause requires an analytics layer to compute state-change durations from that raw signal.

What does unplanned downtime typically cost a manufacturing plant?

Unplanned downtime is commonly cited across the industry as a major cost driver, though published figures vary widely by plant size, industry, and methodology.

Is a data historian the same thing as a time-series database?

Related but distinct. A time-series database is a general-purpose storage engine optimized for time-stamped data. A historian is a specialized application built on top of, or instead of, one, with OT-specific protocol connectors and industrial tooling.