---
title: "Plant Historian: What It Captures"
description: "A plant historian captures raw factory data. Learn what it stores, where OEE and analytics begin, and when to pair it with Postgres."
section: "Postgres for IoT"
---

> **TimescaleDB is now Tiger Data.**

## 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 [<u>what is a data historian</u>](https://www.tigerdata.com/learn/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 [<u>Ask Your Factory Floor Anything</u>](https://www.tigerdata.com/blog/ask-factory-floor-anything-structuring-industrial-data-ai-agents) and [<u>Unified Namespace</u>](https://www.tigerdata.com/blog/unified-namespace-historian-schema) 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 [<u>continuous aggregate</u>](https://www.tigerdata.com/docs/learn/continuous-aggregates) 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: [<u>hypertables</u>](https://www.tigerdata.com/docs/learn/hypertables/understand-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 [<u>Manufacturing Analytics Database guide</u>](https://www.tigerdata.com/learn/manufacturing-analytics-database) 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. [<u>United Manufacturing Hub</u>](https://www.tigerdata.com/case-studies/united-manufacturing)'s open-source stack and [<u>Takton's Sense machine-monitoring platform</u>](https://www.tigerdata.com/blog/how-startup-takton-shipped-just-two-months-tiger-data) (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 [<u>data historian vs. time-series database</u>](https://www.tigerdata.com/learn/moving-past-legacy-systems-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 [<u>connecting MQTT to PostgreSQL</u>](https://www.tigerdata.com/learn/mqtt-to-postgresql) and [<u>edge database patterns for factory devices</u>](https://www.tigerdata.com/learn/edge-database).

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 [<u>SCADA data management at scale</u>](https://www.tigerdata.com/learn/scada-data-management-at-scale-architecture-historians-and-the-modern-database) 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 [<u>Manufacturing Analytics Database guide</u>](https://www.tigerdata.com/learn/manufacturing-analytics-database).

## Where to Go Deeper

If you need the complete OEE, downtime, and quality-and-production schema and SQL patterns, the [<u>Manufacturing Analytics Database guide</u>](https://www.tigerdata.com/learn/manufacturing-analytics-database) 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.