Data historians and time-series databases solve different layers of the IIoT stack, and the 2026 consensus across vendor and integrator literature is that they run side-by-side rather than as a replacement pair [S1][S2][S3].
A data historian ingests time-stamped values from PLCs, DCS, and SCADA over native OT protocols (OPC-UA, OPC-DA, Modbus, and vendor-specific links) and writes each reading as tag + timestamp + value + quality code [S1][S2]. A time-series database (TSDB) is engineered for the IT side: HTTP APIs, Kafka/MQTT brokers, Telegraf agents, and SQL/PostgreSQL-compatible query layers with columnar compression and horizontal scaling [S1][S2][S3]. The framing that frames them as binary competitors is the most common reason teams buy the wrong tool [S1].
Side-by-Side Criteria: Historian vs TSDB on 10 Decision Axes
Primary design purpose splits sharply: historians target OT data collection, operator trending, and compliance-grade audit trails, while TSDBs target SQL-accessible analytics, ML pipelines, and cross-series joins [S1][S2]. The data model diverges next: historians are tag-centric (one record per measurement point with a quality code per write), whereas TSDBs are table- or series-centric with flexible schemas and no native quality flag [S1][S2].
Query language is the second hard split. Historians expose proprietary APIs (PI AF/SDK, AspenOne, OSIsoft AF) that plant operators already know; TSDBs expose standard SQL with window functions, continuous aggregates, and joins, which data-engineering teams can use without retraining [S1][S2]. OT protocol support favors historians: native OPC-UA, OPC-DA, Modbus, and DCS connectors versus a required bridge layer (Ignition, Telegraf, MQTT) on the TSDB side [S1][S2]. Compression differs in mechanism: historians use exception reporting and swinging-door algorithms tuned for step-function process signals, while TSDBs use columnar compression (Hypercore and similar engines report 90 to 98 percent storage reduction) [S2].
Scalability economics flip the cost curve: historian licensing is per-tag or per-server, which becomes punitive above roughly 100,000 tags, while TSDBs charge on usage (compute + storage) with no per-tag fee and scale horizontally [S2]. BI tool access is native-SQL on the TSDB side (Grafana, Tableau, dbt, Superset, Jupyter via PostgreSQL wire protocol) versus proprietary historian APIs with limited native connectors [S2]. Deployment defaults still favor on-premises for historians with cloud as an add-on, while TSDBs ship managed-cloud-first (AWS/Azure) plus self-hosted [S1][S2]. Compliance is the historian's strongest single card: FDA 21 CFR Part 11 audit trails, OPC quality codes, and batch records are built in, whereas TSDBs offer ACID compliance and custom audit tables but no native quality codes [S2].
OT Connectivity: The Bridge Problem That Decides Architecture
OPC-UA, OPC-DA, and Modbus remain the lingua franca of the plant floor, and historians speak them natively; TSDBs typically do not, which is the single most consequential integration cost in any IIoT TSDB rollout [S1]. The standard pattern documented across vendor playbooks in 2024 to 2026 is to install a connector layer such as Telegraf, Ignition, or an MQTT bridge in front of the TSDB and leave the historian in place as the OT-side system of record [S1][S2][S4].
This is why the dominant 2024 to 2026 pattern is parallel operation, with the historian handling acquisition, validation, and quality-coded writes, and the TSDB handling downstream SQL analytics, BI dashboards, and ML feature extraction [S2][S3][S4]. Quality codes are the specific historian feature a TSDB cannot easily replicate: each historian write carries a status byte (good, bad, substituted, manual entry) that auditors and operators rely on, and most TSDB schemas leave that field to application code [S1][S2].
Compression, Scale, and Storage Cost: Where TSDBs Win on Economics
At IIoT scale, per-tag licensing is the cost line that breaks historian economics above 100,000 tags, while TSDBs with usage-based pricing and columnar compression report 90 to 98 percent storage savings versus uncompressed row-store baselines [S2]. Hypercore and similar columnar engines, plus diskless architectures that persist compressed Parquet files to object storage, separate compute from storage and let storage tiers age data automatically [S2][S3].
For a 1-million-tag plant, the realistic 2026 outcome is a hybrid: historian retains hot regulatory and operator data; TSDB owns warm/cold analytics at object-store economics, often with Apache Arrow and Parquet as the on-disk format for direct consumption by Python, Spark, and BI tools [S3]. This is also why the InfluxData practical-path guidance and the CrateDB comparison both recommend incremental adoption rather than big-bang replacement [S1][S3].
Compliance and Audit: Why Regulated Lines Keep the Historian
FDA 21 CFR Part 11, OPC quality codes, and electronic batch records are the three compliance primitives historians ship out of the box; TSDBs deliver ACID transactions and custom audit tables, but quality codes and batch context have to be modeled in the application layer [S2]. Pharmaceutical, oil and gas, and regulated chemical plants continue to keep the historian as the audit-grade system of record, and route a TSDB copy downstream for analytics that do not require 21 CFR Part 11 immutability [S2][S5].
Air-gapped OT network deployment is the second reason historians persist: production data cannot leave the facility, so the historian stays in the OT enclave while a unidirectional gateway or historian-replication layer feeds a TSDB in the IT/DMZ zone for cross-plant analytics [S1][S5]. This split is also why the term has shifted from "data historian" to "operational data infrastructure" in some vendor literature: the historian is being repositioned as the OT data layer, not the analytics layer [S5].
When to Keep, Augment, or Replace: A Use-Case Decision Matrix
Keep the historian as-is if you are on a regulated line, depend on PI AF / AspenOne asset models, or run air-gapped OT networks where 21 CFR Part 11 audit trails and OPC quality codes are non-negotiable [S2][S5]. Augment with a TSDB in parallel when the bottleneck is SQL access for IT teams, BI dashboards via Grafana/Tableau, ML pipelines for predictive maintenance, or cross-plant joins that the historian's tag-retrieval model cannot express [S2][S3][S4].
Replace the historian only when per-tag licensing cost above 100,000 tags is unsustainable AND the OT connectivity problem has been independently solved with a sustainable bridge layer, AND the regulatory audit chain is not the binding constraint [S2]. For most plants the migration cost and risk do not clear that bar, which is why the most common real-world outcome documented in 2024 to 2026 is historian plus TSDB in parallel, not a like-for-like swap [S2][S3][S4]. Engineers evaluating data loggers on the plant floor also face the same layering decision, since acquisition hardware has to match the historian's protocol set before any TSDB discussion starts. The crawl-walk-run migration path (Telegraf pilot, then per-silo replication, then full TSDB integration) is the playbook recommended in 2024 to 2026 for an incremental shift without operational risk [S4].
Limits, Failure Modes, and What Neither System Solves
Historians do not natively do cross-asset analytics, cross-plant joins, ERP/MES context enrichment, or OEE calculations across multiple production lines; their model is tag retrieval, not relational analytics [S1]. TSDBs do not natively speak OPC-UA or Modbus, and they do not ship quality codes or 21 CFR Part 11 audit trails out of the box; both must be added at the connector or application layer [S1][S2]. The failure mode most cited in the literature is treating the choice as binary and either overpaying for a historian stretched into an analytics role or under-engineering the OT bridge for a TSDB that cannot ingest from PLCs by itself [S1][S6].
The 2026 plant-level recommendation: the historian stays on the OT network as the system of record, the TSDB sits in the IT/DMZ zone as the analytics and ML layer, and a unidirectional gateway or Telegraf/Ignition bridge handles the cutover; the engineering judgement is about which class of workload you are deploying for, not which database to keep [S1][S2][S6]. Teams that frame the problem this way avoid the trap of paying twice (per-tag historian fees AND cloud TSDB fees) for the same data, which is the cost pattern that triggers replacement evaluations in the first place [S2].
Trackable signals through the rest of 2026: AVEVA PI license-model changes (already flagged in 2024 to 2026 evaluation timing discussions) and TSDB-vendor releases of native OPC-UA ingestion or built-in quality-code columns, both of which would shift the parallel-default recommendation toward a more consolidated stack [S2]. Until those land, the parallel pattern is the lowest-risk, lowest-disruption default for any plant above 50,000 tags or with a regulatory audit chain attached. For a deeper look at the OT/IT boundary that drives this layering, see Manufacturing Data Governance: Ownership, Quality, and the OT/IT Boundary, and for the upstream contextualization step that determines whether a historian tag is usable, see Why Raw PLC Tags Are Useless Without Data Contextualization.
Component reference pages worth checking: time relay, and pressure transmitter.