The Historian Evaluation Playbook
How Digital Transformation Teams Should Choose, Upgrade, or Replace Their Industrial Data Historian
introduction
The Hidden Tax on Your Digital Transformation
Every manufacturer's digital transformation roadmap eventually runs into the same wall: the data historian.
Not always because the historian is apparently broken. In fact, it may be working fine, collecting data reliably, humming along the way it has for a decade. The problem is that "fine" is no longer good enough. Your DX roadmap depends on contextual, real-time, AI-accessible data flowing freely across your organization. Your existing historian was designed for a world where that wasn't even a concept.
The industrial data historian is the most critical and most overlooked infrastructure decision in modern OT/IT convergence. Get it right, and your AI initiatives, unified namespace architecture, and real-time analytics pipelines have a solid foundation. Get it wrong, ignore it and leave an aging system in place because "if it ain't broke…" and you're paying a hidden tax on every digital initiative that follows.
This playbook is written for Digital Transformation teams who are making one of these decisions:
- Selecting a historian for the first time as part of a greenfield or brownfield DX program
- Evaluating whether the current historian is a strategic asset or a strategic liability
- Building the business case to replace an incumbent vendor
- Considering whether trying to standardize historian solutions across multiple operations is viable and wise
- Evaluating open-source database alternatives as potential historian foundations
- Running a side-by-side pilot to validate a modern alternative
Part I documents the five most common and most damaging failure patterns of underperforming historians, examined through the lens of the two engineering roles who live with the consequences every day. Part II evaluates why open-source time-series databases, despite their technical merit, are not historian solutions. Parts III through VII give you the evaluation framework, cost analysis, benchmarking methodology, business case structure, and 30-day action plan to move from diagnosis to decision.
Understanding the two engineering archetypes
To understand why historian limitations are as damaging as they are, you need to understand who bears the pain and how differently that pain manifests depending on your role.
PERSONA ONE
The Process Controls Engineer
The Process Controls Engineer (PCE) lives in the deterministic world of the shop floor: PID loops, PLC ladder logic, valve positions, and millisecond-level troubleshooting. For the PCE, the historian is a diagnostic instrument. When something goes wrong on the line, the historian is the first tool reached for. Speed, resolution, and data completeness are not nice-to-haves, they are the difference between finding root cause in an hour and spending a week in the dark.
PERSONA TWO
The Application Engineer
The Application or Systems Engineer operates at the intersection of OT and IT. They care about APIs, scalability, semantic data models, and the pipelines that move process data into dashboards, ML models, enterprise data lakes, and AI-enabled workflows. For the Application Engineer, the historian is infrastructure. Its quality determines whether every downstream initiative gets clean, structured, accessible data, or a war story about a workaround that took three months to build.
When a historian underperforms, both archetypes suffer but the symptoms look completely different. The five failures documented in this section were identified through direct engineering feedback. They are presented through both lenses, because the path to organizational buy-in on a historian replacement requires fluency in both languages.
PART ONE
The Five Systematic Failures
Why your historian is holding your digital transformation back
1
High-Latency Queries and Restricted Extraction
The "Data Archeology" Problem
When an incident occurs or an optimization model needs training, engineers must query large blocks of time-series data. Legacy historians were not designed for the query patterns that DX programs demand. They lack efficient distributed indexing for high-cardinality datasets, and their query engines were built for the reporting workloads of the 1990s, not the concurrent, real-time API calls that modern dashboards, ML pipelines, and AI agents require.The result is an infrastructure that bottlenecks at exactly the moment it is most needed: during a live process upset, a root cause investigation, or a data science sprint. Engineers learn to work around the constraint, scheduling large extracts at off-hours, reducing query scope, or simply accepting that trending large datasets will be a slow, unreliable experience.
PROCESS CONTROLS ENGINEER PERSPECTIVE
The Process Controls Engineer
"When a critical valve starts oscillating, I need to pull high-resolution (sub-second) trends right now to tune the PID loop. If the historian takes 15 minutes just to render a 24-hour trend, or drops my connection halfway through, I'm flying blind while the process drifts out of spec."
APPLICATION ENGINEER PERSPECTIVE
The Application Engineer
"The business wants a real-time dashboard or a predictive maintenance model. But every time my Python scripts or BI tools make an API call to extract a month's worth of data for 500 tags, the historian's proprietary backend throttles the request or times out. We are forced to schedule giant batch extracts at 2:00 AM just to keep the server from crashing."
In the Field: How Legacy Vendors Handle This
AVEVA PI System (formerly OSIsoft PI): PI Web API provides RESTful access to PI data but carries significant performance constraints on bulk time-range queries across large tag sets. PI Data Archive's archive file structure is optimized for sequential write — not the random-access, high-concurrency read patterns that BI and AI tools require. The PI SDK remains the highest-performance interface, which means every integration requires licensed client software and its own maintenance burden.
GE Proficy Historian: Under concurrent query load, Proficy's proprietary query engine shows measurable latency degradation. Organizations running multiple simultaneous reporting workloads alongside real-time collection report connection timeouts and server instability — forcing large extracts to maintenance windows.
Honeywell Uniformance PHD: Querying PHD requires the Uniformance Suite client software or the PHD SDK. There is no documented public REST API. Every integration carries vendor client licensing, proprietary middleware, and the latency of that translation layer.
GE Proficy Historian: Under concurrent query load, Proficy's proprietary query engine shows measurable latency degradation. Organizations running multiple simultaneous reporting workloads alongside real-time collection report connection timeouts and server instability — forcing large extracts to maintenance windows.
Honeywell Uniformance PHD: Querying PHD requires the Uniformance Suite client software or the PHD SDK. There is no documented public REST API. Every integration carries vendor client licensing, proprietary middleware, and the latency of that translation layer.
What Good Looks Like: Timebase Historian
Timebase provides a REST API designed for concurrent, high-cardinality queries and a WebSocket push channel that eliminates polling latency entirely. Downstream consumers (dashboards, ML pipelines, AI agents) receive data within milliseconds of collection. No proprietary client software. No batch window workarounds.
2
Aggressive Compression Loss
The "Ghost in the Data" Problem
Legacy historians often rely heavily on compression algorithms, most commonly the Swinging Door algorithm. They do this to manage the disk space demands of continuous data collection at scale; consider the potential size of a database that collects 5,000 tags every second, possibly seeing more than 400,000,000 values per day. The principle is logical: if a process value does not change significantly between two time steps, discard the intermediate points and reconstruct the curve from endpoints. In theory, this preserves the shape of a trend while eliminating redundant data.
In practice, when compression parameters are configured aggressively to manage storage costs, the algorithm deletes data that is not redundant at all. The result? Brief transient events that fall within the configured deviation deadband are discarded at ingestion as if they never occurred.The data is permanently gone. It cannot be recovered. And for engineers who do not know to look for it, its absence is invisible: the trend appears smooth and normal because the anomaly that caused a failure was never written to disk.
PROCESS CONTROLS ENGINEER PERSPECTIVE
The Process Controls Engineer
"The vendor's dead-band compression is so aggressive to save storage that it flatlines brief, critical anomalies. A 200 ms pressure spike that fractured a pipe casing looks like a smooth, normal line in the historian because the data points were discarded at ingestion. We literally cannot find the root cause of mechanical failures."
APPLICATION ENGINEER PERSPECTIVE
The Application Engineer
"I'm trying to feed data into a Machine Learning model for predictive quality analytics. Because the historian strips out the micro-variations and "noise" to keep file sizes small, the dataset lacks the variance needed for training. The saying holds true: garbage in (or in this case, empty data in), garbage out."
In the Field: How Legacy Vendors Handle This
AVEVA PI System: PI uses exception-based storage controlled by compression deviation and shutdown deviation parameters. Default factory settings balance compression ratio against data fidelity, but the default balance favors compression. A 200 ms pressure spike within the compression deadband is potentially discarded. PI's compression is tunable per tag, but configuring it for lossless behavior requires per-tag administration effort and significantly increases storage requirements, which feeds back into the tag tier licensing cost.
AVEVA Wonderware Historian: Wonderware's InSQL backend applies compression at the collection layer. Default exception deviation settings for analog tags will miss transient events shorter than the configured deadband. Default configurations in most operational deployments prioritize storage efficiency over process fidelity.
GE Proficy Historian: Proficy uses the Swinging Door algorithm with configurable deviation parameters. Factory-default settings are calibrated for the storage hardware of a decade ago — meaning aggressive compression that loses the micro-variations modern ML training requires.
AVEVA Wonderware Historian: Wonderware's InSQL backend applies compression at the collection layer. Default exception deviation settings for analog tags will miss transient events shorter than the configured deadband. Default configurations in most operational deployments prioritize storage efficiency over process fidelity.
GE Proficy Historian: Proficy uses the Swinging Door algorithm with configurable deviation parameters. Factory-default settings are calibrated for the storage hardware of a decade ago — meaning aggressive compression that loses the micro-variations modern ML training requires.
What Good Looks Like: Timebase Historian
Timebase Historian uses lossless storage by default. Every data point collected is stored at full resolution. This is a deliberate architectural choice that matters for AI/ML use cases and root cause investigations alike. Storage efficiency is achieved through efficient binary encoding, not through discarding data. For organizations migrating from a lossy historian, a side-by-side comparison will frequently reveal that significant process variation was being silently discarded for years.Canary Labs also features a lossless storage optimizing a delta compression mechanism. Rather than storing the raw data values, Canary records the original data value in the HDB2 file, then stores the delta of each subsequent value.
3
Rigid, Fragmented Tag Architecture and Lack of Context
The "TAG SOUP" Problem
The earliest industrial historians modeled their tag structure on the instrument naming conventions already in use on the shop floor. Flat identifiers like FIC_101.PV, TIC_204.SV, or PUMP_07_STATUS were used, a practical choice in an era when historians served a single site with a single engineering team that knew every tag by name. As manufacturing operations have grown in scale (multiple sites, product lines, heterogeneous equipment from multiple vendors) the flat tag model has become a structural liability. Case-in-point, look at the soaring popularity of post-archive data modeling tools by vendors like AVEVA PI (PI AF) and Canary Labs (Virtual Views).
Without native asset framing, ISA-95 hierarchies, or semantic metadata, raw historian tags are context-free identifiers. They record what was measured; they do not record what equipment it belongs to, what operating state the asset was in, what product was being produced, or where in the enterprise the measurement occurred. Every downstream consumer must reconstruct this context from scratch.
Without native asset framing, ISA-95 hierarchies, or semantic metadata, raw historian tags are context-free identifiers. They record what was measured; they do not record what equipment it belongs to, what operating state the asset was in, what product was being produced, or where in the enterprise the measurement occurred. Every downstream consumer must reconstruct this context from scratch.
PROCESS CONTROLS ENGINEER PERSPECTIVE
The Process Controls Engineer
"Every time we modify a PLC program or add a new instrument, I have to manually map and configure the tags in the historian, ensuring the scanning rates match. If the historian doesn't support open standards like OPC UA natively, I waste hours building custom device drivers just to get data flowing."
APPLICATION ENGINEER PERSPECTIVE
The Application Engineer
"To me, raw tags are just a meaningless "tag soup." Without semantic metadata or an asset model, I don't know if TEMP_04 belongs to the distillation column in Texas or the mixer in Ohio. I have to manually write massive translation tables in SQL or JSON to add context — Batch ID, Product SKU, Equipment State — before the data is usable by the enterprise."
In the Field: How Legacy Vendors Handle This
AVEVA PI System: PI Asset Framework (AF) is a powerful asset modeling layer that can organize PI tags into equipment hierarchies and business objects. But PI AF requires dedicated expertise to configure and maintain. Organizations without a certified PI administrator often leave AF unconfigured, running on the flat tag foundation beneath it. When AF is properly deployed it is capable; when it is not — which is common — the underlying flat structure provides no asset context.
AVEVA Wonderware: Wonderware's System Platform (ArchestrA) provides object-based hierarchy when fully deployed. However, this is tightly coupled to the full Wonderware SCADA/HMI ecosystem. Organizations running Wonderware Historian as a standalone product without System Platform get a flat-tag historian with no native asset model.
GE Proficy Historian: Flat tag model with no native asset hierarchy. Asset context must be built externally in GE Plant Applications or Operations Hub — creating a mandatory dependency on the broader GE software stack for any contextualized analytics use case.
AVEVA Wonderware: Wonderware's System Platform (ArchestrA) provides object-based hierarchy when fully deployed. However, this is tightly coupled to the full Wonderware SCADA/HMI ecosystem. Organizations running Wonderware Historian as a standalone product without System Platform get a flat-tag historian with no native asset model.
GE Proficy Historian: Flat tag model with no native asset hierarchy. Asset context must be built externally in GE Plant Applications or Operations Hub — creating a mandatory dependency on the broader GE software stack for any contextualized analytics use case.
What Good Looks Like: Timebase Historian
OPC UA is one of the key differentiators here. OPC UA includes a native information model; a structured asset hierarchy that defines equipment, components, and their relationships as part of the protocol itself, not as a separate software layer. A historian that collects OPC UA data natively inherits this asset model at the point of collection. Likewise, an MQTT payload can also contain valuable context in the structured hierarchy.Timebase collects OPC UA and MQTT (Sparkplug and vanilla JSON) natively, which means asset and namespace context flows into the historian automatically, without external configuration layers or translation tables.
4
Proprietary Silos and Poor IT/OT Interoperability
The "mars vs venus" Problem
Industrial historians from the major legacy vendors were designed in a world where the historian was the center of the data universe. As such, they were the single system all OT data flowed into, and the single system all analytics flowed out of. Vendor incentives to maintain this position led to architectural choices that are difficult to defend in a modern DX context: proprietary binary storage formats with no documented export path, access APIs that require licensed vendor client software, and deliberate gaps in support for open standards like MQTT, SparkplugB, and modern cloud data formats.
The result is a pattern that OT/IT convergence practitioners recognize immediately: OT systems and IT systems are speaking fundamentally different languages, and the historian, instead of bridging the gap, is a wall between them.
The result is a pattern that OT/IT convergence practitioners recognize immediately: OT systems and IT systems are speaking fundamentally different languages, and the historian, instead of bridging the gap, is a wall between them.
PROCESS CONTROLS ENGINEER PERSPECTIVE
The Process Controls Engineer
"The historian is tightly bound to our specific SCADA/DCS vendor ecosystem. Because it doesn't play nice with newer edge-IoT gateways we want to deploy on the line, we are forced to keep maintaining brittle, legacy Windows servers right next to the machine floor."
APPLICATION ENGINEER PERSPECTIVE
The Application Engineer
"Modern software architecture relies on open, flexible ecosystems. If I want to pipe data into an enterprise data lake like Snowflake or Databricks for multi-site cross-benchmarking, this historian acts as a roadblock. We have to build and maintain complex, bespoke ETL pipelines just to translate their proprietary format into standard JSON or other required formats."
In the Field: How Legacy Vendors Handle This
AVEVA PI System: PI data is stored in PI Data Archive files (.arc), a proprietary binary format with no documented open-standard equivalent. External access requires PI Web API (licensed), PI OLEDB Enterprise (licensed), PI JDBC Driver (licensed), or the PI SDK (licensed). Every path from PI data to a Snowflake or Databricks data lake runs through a custom integration or AVEVA-provided connector, or AVEVA Connect, requiring its own licensing and maintenance cycle.
AVEVA Wonderware Historian: Wonderware's InSQL backend is SQL Server-based, providing a more accessible path than PI's archive files. However, the InSQL schema is complex and Wonderware-specific; direct SQL queries risk correctness issues. Supported external access is through OPC HDA or the Wonderware Industrial Application Server. Neither speaks modern REST, WebSocket, or streaming protocols.
GE Proficy Historian: GE Proficy stores data in proprietary binary files (.ihc). External access requires the Historian OPC HDA Server, iHistorian SDK, or ODBC connector. There is no native documented REST API. Cloud connectivity requires GE's Operations Hub middleware or custom ETL development.
Honeywell Uniformance PHD: Proprietary PHD storage accessed through the Uniformance Suite client or OPC HDA. REST capabilities are minimal. Integration with modern data platforms requires custom middleware or the Uniformance Asset Sentinel toolkit — additional licensed components.
AVEVA Wonderware Historian: Wonderware's InSQL backend is SQL Server-based, providing a more accessible path than PI's archive files. However, the InSQL schema is complex and Wonderware-specific; direct SQL queries risk correctness issues. Supported external access is through OPC HDA or the Wonderware Industrial Application Server. Neither speaks modern REST, WebSocket, or streaming protocols.
GE Proficy Historian: GE Proficy stores data in proprietary binary files (.ihc). External access requires the Historian OPC HDA Server, iHistorian SDK, or ODBC connector. There is no native documented REST API. Cloud connectivity requires GE's Operations Hub middleware or custom ETL development.
Honeywell Uniformance PHD: Proprietary PHD storage accessed through the Uniformance Suite client or OPC HDA. REST capabilities are minimal. Integration with modern data platforms requires custom middleware or the Uniformance Asset Sentinel toolkit — additional licensed components.
What Good Looks Like: Timebase Historian
Timebase exposes a fully documented REST API, supports CESMII's i3X API, includes WebSocket push, and provides an MCP server with prebuilt agentic tooling. Data flows into Snowflake, Databricks, Power BI, Grafana, or any AI agent through standard interfaces. No proprietary client software. No vendor middleware. No custom ETL for the core integration.
5
Exploding Licensing Costs and Scalability Bottlenecks
The "tag Tax" Problem
The per-tag licensing model is the most pervasive structural deficiency in the legacy historian market.
Introduced in the early 1990s, when historian installations were small and tag counts were established at deployment, per-tag pricing made economic sense for its era. As license counts grew into the thousands, then the tens and hundreds of thousands, and finally enterprise systems with millions of tags, the only beneficiary became the software vendor. It was not, and still is not, uncommon for manufacturers to suffer millions of dollars of licensing costs for these per-tag business models. The benefit lies solely with the vendor, helping OSIsoft gain a multi-billion valuation when AVEVA acquired them several years ago.
In the context of a modern DX program a per-tag pricing is a direct tax on digital transformation itself.
Imagine having to pay per-tag for sensor storage when IIoT initiatives add sensors continuously, digital twins require high-frequency data from hundreds of instruments, and modern smart field devices generate dozens of diagnostic tags per device. It is a blocker and will kill a DX initiative before it ever proves value.
Furthermore, modern instruments are no longer single-variable devices. A smart transmitter generates a primary process variable alongside diagnostic tags for internal temperature, vibration, signal quality, health status, and device error codes. A DX program that wants to capture the full value of smart instrumentation needs to collect all of it. Under a per-tag licensing model, that decision requires a budget conversation. The tag tax forces an organizational choice: collect the data that informs better operations, or stay within the licensing tier.
In the context of a modern DX program a per-tag pricing is a direct tax on digital transformation itself.
Imagine having to pay per-tag for sensor storage when IIoT initiatives add sensors continuously, digital twins require high-frequency data from hundreds of instruments, and modern smart field devices generate dozens of diagnostic tags per device. It is a blocker and will kill a DX initiative before it ever proves value.
Furthermore, modern instruments are no longer single-variable devices. A smart transmitter generates a primary process variable alongside diagnostic tags for internal temperature, vibration, signal quality, health status, and device error codes. A DX program that wants to capture the full value of smart instrumentation needs to collect all of it. Under a per-tag licensing model, that decision requires a budget conversation. The tag tax forces an organizational choice: collect the data that informs better operations, or stay within the licensing tier.
PROCESS CONTROLS ENGINEER PERSPECTIVE
The Process Controls Engineer
"Modern smart instruments generate dozens of diagnostic tags: vibration, internal temperature, health status, etc., alongside the primary process variable. Because of the vendor's strict "tag tax," management forces us to pick and choose what we historize. We intentionally leave valuable machine-health data unrecorded just to avoid triggering a massive license upgrade cost."
APPLICATION ENGINEER PERSPECTIVE
The Application Engineer
"We are trying to roll out a digital transformation initiative across five different plants. The vendor's technology can't scale elastically or handle cloud-native load balancing. To scale up, we are forced to buy expensive, specialized on-premise hardware and pay exponential licensing fees. The ROI of our Industry 4.0 roadmap gets completely killed by the historian's cost structure."
In the Field: How Legacy Vendors Handle This
AVEVA PI System: PI System uses tag-based licensing in count tiers, with extremely hard to justify pricing steps at count thresholds. Moving from one tier to the next requires procurement engagement, AVEVA licensing team involvement, and a maintenance fee recalculation. Annual PI System maintenance fees run 18–22% of original license value per year. For a medium-scale manufacturer at 50,000–100,000 tags, the combined annual licensing and maintenance cost commonly reaches seven figures… paid for the right to store data the manufacturer already owns.
AVEVA Wonderware Historian: Wonderware uses per-tag licensing with enterprise editions required for high tag counts. Multi-site deployments require site licenses and tag count upgrades at each location.
GE Proficy Historian: Per-tag licensing with count-based tier pricing. Scaling across multiple plants requires site licenses and tag upgrades at each facility.
Honeywell Uniformance PHD: Per-point (tag) licensing model with count-based upgrade pricing. Diagnostic and health tags from smart instrumentation count against the licensed point total.
AVEVA Wonderware Historian: Wonderware uses per-tag licensing with enterprise editions required for high tag counts. Multi-site deployments require site licenses and tag count upgrades at each location.
GE Proficy Historian: Per-tag licensing with count-based tier pricing. Scaling across multiple plants requires site licenses and tag upgrades at each facility.
Honeywell Uniformance PHD: Per-point (tag) licensing model with count-based upgrade pricing. Diagnostic and health tags from smart instrumentation count against the licensed point total.
What Good Looks Like: Timebase Historian
Timebase Historian is completely and forever free, there is no paywall or pay gate. No tag limits, no feature tiers, no count-based thresholds, no maintenance fees. Tag count is an operational decision. A DX team deploying Timebase across five plants does not need a budget conversation about tag count. Every smart instrument diagnostic tag, every IIoT data stream, every digital twin feed can be collected without triggering a licensing event.
Summary
Impact Statement
PART TWO
The Open Source Historian Trap
Why InfluxDB, QuestDB, and TimescaleDB are not historian solutions
Critical distinction
An Open Source Database Is Not a Product
When DX teams start evaluating historian alternatives, an appealing path often surfaces: why not build on a proven open source time series database?
InfluxDB, QuestDB, and TimescaleDB are genuinely excellent databases. Their query performance, storage efficiency, and developer ergonomics are well-documented and well-regarded. The appeal is obvious: proven technology, no licensing cost, and complete control over the architecture.
But the premise contains a critical category error. A time-series database is not a historian product. It is one component of a historian product, specifically, the storage and query layer. And while that component matters, it represents a fraction of what an industrial data historian actually is.
Understanding this distinction is essential for any DX team considering an open-source database as a historian foundation, because the costs of the error are not visible on a procurement spreadsheet. They show up six months into the build, or two years later when the engineer who designed the system moves on.
InfluxDB, QuestDB, and TimescaleDB are genuinely excellent databases. Their query performance, storage efficiency, and developer ergonomics are well-documented and well-regarded. The appeal is obvious: proven technology, no licensing cost, and complete control over the architecture.
But the premise contains a critical category error. A time-series database is not a historian product. It is one component of a historian product, specifically, the storage and query layer. And while that component matters, it represents a fraction of what an industrial data historian actually is.
Understanding this distinction is essential for any DX team considering an open-source database as a historian foundation, because the costs of the error are not visible on a procurement spreadsheet. They show up six months into the build, or two years later when the engineer who designed the system moves on.
What a Complete Historian Product Delivers
An industrial data historian is not a time-series database. It is a complete operational technology solution that includes, at minimum, all of the following:
- Industrial data collection: Native OPC UA, MQTT, SparkplugB, and API collectors that connect directly to existing operational servers, gateways, and SCADA applications
- Store-and-forward buffering: Persistent local queuing that captures data during network outages and replays it to the archive when connectivity is restored, with no data loss or manual intervention
- Redundancy architecture: Active-active failover at both the collector and storage layer, ensuring continuous collection even during node failure
- Late-write and arrive-late data handling: A defined behavior model for data that arrives out of sequence, from edge buffers, reconnected collectors, or manual backdated entry
- Compression and data validation utilities: Tools to configure compression parameters, identify and repair gaps, detect duplicate records, and validate archive integrity
- Tag management: A configuration interface for defining tags, engineering units, scan rates, deadbands, and metadata; all manageable by OT engineers, not just software developers or IT teams
- Trending and visualization: Built-in process trend display that OT engineers can use to display real time or historic data without writing code
- Role-based access control: Security model appropriate for OT environments, where read-only access for operators is as important as write access for engineers
- Operational monitoring and alerting: Health status of the historian itself, including collection rates, buffer depth, storage utilization, connectivity status
What You Are Actually Building
When your team deploys InfluxDB, or the like, as an industrial historian, none of the above exists out of the box. Your IT or OT team must design, build, test, document, and maintain every layer.
Someone has to write or tune the collector. Someone has to build the MQTT bridge. Someone has to implement store-and-forward logic in the edge buffer so that a 30-minute network outage does not produce a 30-minute gap in the archive or flatline a trend on an operator's screen. Someone has to design the redundancy model, decide what happens during failover, and test that it works. Someone has to build the tag management interface, or decide to operate without one. Someone has to provide trending tools to the process engineers who currently use the historian's built-in client, or explain to them why that capability no longer exists.
When you add up the scope, you are not adopting a database. You are building a historian product internally, using your own engineers' time, funded by your own budget, with your own team bearing the support burden.
Someone has to write or tune the collector. Someone has to build the MQTT bridge. Someone has to implement store-and-forward logic in the edge buffer so that a 30-minute network outage does not produce a 30-minute gap in the archive or flatline a trend on an operator's screen. Someone has to design the redundancy model, decide what happens during failover, and test that it works. Someone has to build the tag management interface, or decide to operate without one. Someone has to provide trending tools to the process engineers who currently use the historian's built-in client, or explain to them why that capability no longer exists.
When you add up the scope, you are not adopting a database. You are building a historian product internally, using your own engineers' time, funded by your own budget, with your own team bearing the support burden.
The Hidden Long-Term Costs
The build cost is only the beginning. Once your custom historian is in production, ongoing costs include:
- Maintenance ownership: Every database version upgrade, security patch, and breaking API change is your team's responsibility. There is no vendor support for the custom collector you built on top of InfluxDB v2 when you upgrade to v3.
- The bus factor: Your custom historian was designed and built by a small number of engineers. When one of them moves to a different role or a different company, the institutional knowledge leaves with them. Documentation is typically incomplete. The next engineer inherits a system they did not design, written in patterns they did not choose.
- Regulatory and audit risk: Industrial historians in regulated manufacturing environments often need to demonstrate data integrity, audit trails, and validated configurations. A custom-built system has no certification. Your team is responsible for demonstrating compliance for every audit.
- Perpetual feature gap: The incumbent historian vendors have invested decades in the capabilities their products provide. Closing that gap through internal development is a multi-year commitment. The DX team that started to save on licensing costs ends up operating a permanent internal product team.
- Growth and standardization:As new sites are brought under management, you will continue to have to choose whether you will standardize on your home-grown solution. To do so will require a massive undertaking to rip and replace existing historian architecture with your internal solution, all for the sake of internal product support rather than external vendor engagements.
the honest question
Before choosing an open-source database as your historian foundation, scope the full build honestly: OT connectors, store-and-forward, redundancy, late-write handling, trending tools, tag management, and operational monitoring. Then ask whether that engineering investment is better spent building and maintaining infrastructure, or delivering the operational outcomes your DX program was designed to achieve.
A Note on Each Platform
InfluxDB
InfluxDB is one of the most widely deployed time-series databases in the world, and its query performance and developer ergonomics are genuine strengths. However, InfluxDB v3 (IOx) moved from the Apache 2.0 license to the Business Source License (BSL). Commercial use above certain thresholds now requires a commercial license. Organizations that built historian infrastructure on InfluxDB v2 under the assumption of a permanent open-source license face a migration decision or a licensing conversation they did not plan for. The "free open source" premise that made InfluxDB appealing as a historian foundation is no longer straightforwardly true.
TimescaleDB
TimescaleDB is a PostgreSQL extension; a solid choice for time-series workloads running on existing PostgreSQL infrastructure. But it carries PostgreSQL's operational overhead: WAL management, vacuuming, connection pooling, and DBA expertise requirements. PostgreSQL's I/O model is not optimized for the high-write, time-sequential patterns of industrial data collection at scale. And there is no OT ecosystem around TimescaleDB: no OPC UA connector, no MQTT bridge, no store-and-forward, no HDA server. The entire historian product must be built on top of it.
QuestDB
QuestDB delivers genuinely impressive write throughput and SQL-compatible query performance. For pure time-series analytics workloads, it is a compelling option. But like the others, it provides no OT connectivity, no historian management tools, no redundancy architecture, and no trending interface. It is an excellent database engine in search of a product wrapper — and your team would be writing that wrapper.
A historian is far more than 'just a database'.
The database is not the historian. The historian is the product built around the database. Building that product is a job.
Timebase and Flow Software choose to offer it for free. They have been in your job, they have suffered the alternatives, and they have sworn to fix the industry.
Timebase and Flow Software choose to offer it for free. They have been in your job, they have suffered the alternatives, and they have sworn to fix the industry.
PART three
The Seven Warning Signs
Diagnostic checklist: is your historian a strategic liability?
diagnostic checklist
Warning Signs Your Historian Is Holding You Back
The decision to evaluate a replacement rarely comes from a single catastrophic failure. More often it comes from an accumulation of smaller friction points, each individually tolerable, but collectively a drag on every digital initiative your team is trying to advance. If more than three of the following warning signs describe your current environment, you are already carrying a historian tax.
01
Tag Count Drives Budget Conversations
When every new data point has a cost attached to it, your team starts making architectural decisions based on licensing rather than operational requirements. Engineers aggregate tags to avoid adding raw signals. Projects stall pending licensing approvals. Data that should be collected and archived for future ML training is left uncollected because nobody wants to own the budget conversation.
02
AI and Analytics Teams Cannot Access Historian Data Directly
If your data scientists are pulling historian data through manual exports, scheduled file transfers, or bespoke middleware that one engineer built and only one engineer understands, you have an integration problem that is costing you far more than any licensing fee. Modern DX requires historian data to flow into AI pipelines as naturally as any other data source — through standard APIs, event-driven push mechanisms, or native protocol support.
03
Your Historian Is Windows-Only in a Containerized World
Legacy historian products were built for dedicated Windows servers in the control room. In a modern DX architecture (where workloads run on cloud-connected edge devices, in Docker containers, on hybrid Linux/Windows infrastructure) a Windows-only constraint becomes a deployment liability. Container-first deployment enables repeatable, version-controlled, scalable historian deployments across sites.
04
Each Upgrade Cycle Requires a Vendor Engagement
If your upgrade path requires a professional services engagement, an 18% (and growing) annual maintenance plan, an on-site vendor visit, or a lengthy validation cycle that takes weeks of planning, your historian is not operating at the pace DX demands. Modern software should support upgrade processes that a competent IT or OT team can execute without vendor dependency.
05
You Are Running Parallel Shadow Data Pipelines
When engineers cannot get what they need from the official historian they always build a workaround: a Python script pulling MQTT data into InfluxDB, a cloud Grafana instance connected to a database nobody else knows about, a shared drive of daily CSV exports serving as a de facto data source. These workarounds are signals that the historian is failing the organization's needs and become impossible for the business to govern and use at scale.
06
Your Historian Has No Modern API or Event Push Capability
REST APIs are table stakes for industrial software. Real-time event-driven push via WebSocket is what separates a modern historian from a historical archive with a query interface. If your team's only option for getting data out is a polling loop against a proprietary API or a scheduled ODBC query, you are building batch reporting infrastructure, not real-time digital infrastructure.
07
Redundancy Means "We Have a Backup Server" and Nothing More
True high availability means active-active redundancy: both nodes collecting simultaneously, with automatic failover that causes zero data loss. Most legacy implementations offer active-passive at best, that is a standby server that begins collecting after the primary fails, with a data gap during switchover. For manufacturers where continuity has regulatory, quality, or safety implications, that gap is a data integrity issue, not a minor architectural detail.
ask yourself
Has your team ever decided NOT to collect a data point (or reduced collection frequency) primarily because of historian licensing cost?
If yes, your historian is actively constraining your DX architecture.
If yes, your historian is actively constraining your DX architecture.
PART four
The Evaluation Framework
Eight criteria for selecting an industrial historian
selection framework
The Eight-Criteria Evaluation Framework
Not all historian features carry equal weight for every deployment.
The framework below is designed for DX teams evaluating historians across both current operational requirements and future digital capabilities. Weight each criterion according to your organization's priorities, but do not ignore any! The ones that seem least relevant today are often the ones that block a project two years from now.
The framework below is designed for DX teams evaluating historians across both current operational requirements and future digital capabilities. Weight each criterion according to your organization's priorities, but do not ignore any! The ones that seem least relevant today are often the ones that block a project two years from now.
Individually score each vendor per criterion from the table below on a value of 1 through 5 with 5 being the highest
Next, multiply by the weight, adjust as you see fit. Total your results.
Critical = 5 / High = 4 / Medium-High = 3 / Medium = 2 / Low = 1
Critical = 5 / High = 4 / Medium-High = 3 / Medium = 2 / Low = 1
Any vendor scoring low on Criterion 6 (Licensing) or Criterion 7 (AI Readiness) should be viewed with significant caution regardless of total score
PART five
The Modern Benchmark
Timebase Historian against the eight criteria
reference architecture
Timebase Historian: The Modern Benchmark
Every evaluation needs a benchmark. For this guide, we use Timebase Historian (not because it is the only modern option) but because it addresses all five systemic failures documented in Part I and meets all eight evaluation criteria in Part IV, while eliminating the cost barrier that has historically made historian decisions difficult.
Data Acquisition and Protocol Coverage
Timebase supports OPC UA natively, with MQTT and SparkplugB built into the core platform. This positions it directly in the Unified Namespace architecture where a central MQTT broker serves as the integration backbone and historians subscribe to relevant topics. For brownfield environments, OPC connectivity is available or Timebase provides connection to the Ignition driver utilities via an Ignition by Inductive Automation data collector. Store-and-forward buffering is included at the collector level, ensuring network interruptions do not produce data gaps in the archive.
Licensing and Total Cost of Ownership
This is where Timebase makes its clearest statement. Timebase Historian is completely free. Not free with a tag cap. Not free for a trial period. Not free for a "starter" feature set. Free permanently, unconditionally, for any number of tags, any number of datasets, any number of users, in any deployment environment.
Free. Forever. No Exceptions.
No Tag Limits. No Feature Tiers. No Maintenance Fees.
No Tag Limits. No Feature Tiers. No Maintenance Fees.
The implications for a DX program are significant. Licensing cost is eliminated as a factor in data collection decisions. Tag counts can grow to match operational needs without budget conversations. Every smart instrument diagnostic tag, every IIoT data stream, every digital twin feed can be collected as a matter of operational design, not procurement negotiation.
For digital transformation leadership
AI and Next-Gen Readiness
Every AI initiative in your organization that touches operational data will eventually need to access the historian. A historian with native MCP support lowers the barrier for every subsequent AI use case — it is a force multiplier across your entire AI roadmap.
PART six
Building Your Business Case
Organizational buy-in, TCO modeling, and risk mitigation
decision framing
Framing the Replacement Decision
The technical case for a modern historian is usually straightforward. The organizational case, that is getting leadership alignment and budget approval for a migration, requires a different framing.
Frame It as Infrastructure Modernization
Historian replacements framed as "ripping out the old system" face the highest resistance. Reframe the initiative as infrastructure modernization; the same category of investment as network upgrades, cloud migration, or MES upgrades. The question is not "should we replace the historian?" but "is our data infrastructure ready to support our DX roadmap?" Make a conscious decision to start adding new tags to the new solution, even if complete replacement will take time. Best to start with momentum to the new architecture than continue to sink capital into legacy solutions.
Quantify the Current Historian's True Cost
Build a five-year total cost of ownership model. Include:
Frame It as Infrastructure Modernization
Historian replacements framed as "ripping out the old system" face the highest resistance. Reframe the initiative as infrastructure modernization; the same category of investment as network upgrades, cloud migration, or MES upgrades. The question is not "should we replace the historian?" but "is our data infrastructure ready to support our DX roadmap?" Make a conscious decision to start adding new tags to the new solution, even if complete replacement will take time. Best to start with momentum to the new architecture than continue to sink capital into legacy solutions.
Quantify the Current Historian's True Cost
Build a five-year total cost of ownership model. Include:
- Annual licensing and maintenance fees: current and projected as tag count grows at your DX roadmap pace
- Internal labor: IT/OT staff time for administration, upgrades, and troubleshooting
- External services: vendor professional services, upgrade projects, custom integrations
- Shadow IT: estimated cost of workaround infrastructure and the engineering labor to maintain it
- Opportunity cost: projects delayed or descoped because of historian limitations (quantify at least two)
This number is almost always larger than organizations expect. The licensing line item is visible. The labor, services, and opportunity costs are not — but they are real, and they compound year over year.
Use a Side-by-Side Pilot
The lowest-risk migration path is a parallel pilot: deploy the candidate historian alongside the existing system for 60–90 days, collecting the same data from the same sources. This approach:
Use a Side-by-Side Pilot
The lowest-risk migration path is a parallel pilot: deploy the candidate historian alongside the existing system for 60–90 days, collecting the same data from the same sources. This approach:
- Validates the new historian's performance and reliability without production risk
- Gives engineers and operations staff time to evaluate the new interface
- Produces side-by-side data for quality and completeness comparison
- Creates organizational confidence before the cutover decision
With Timebase, the pilot has zero licensing cost. The evaluation is of the technology, not a commitment to pay for access to it.
Address the Migration Risk Directly
Leadership resistance to historian replacement is most often rooted in risk aversion. Address it with a structured risk mitigation plan:
Address the Migration Risk Directly
Leadership resistance to historian replacement is most often rooted in risk aversion. Address it with a structured risk mitigation plan:
- Parallel operation: both historians run simultaneously, eliminating single-system risk during migration.
- Data validation protocol: documented comparison confirming parity before cutover.
- Data conversion: tools already exist (thanks to integrators like Corso Systems) to migrate AVEVA PI, Wonderware, and Canary data archives to Timebase Historian.
- Phased site rollout: start with a non-critical site or line to validate the migration process.
- Rollback plan: documented criteria and procedure for reverting if needed.
- Training and knowledge transfer: operations and IT staff trained before cutover.
Key Message for Leadership
This is not a question of 'if', this is a question of 'how much longer'
This is not a question of 'if', this is a question of 'how much longer'
The risk of replacing a functional historian is manageable and time-bounded.
The risk of not replacing an aging historian is structural and compounding.
Every year the old system remains, the technical debt grows, the integration gap widens, and the AI readiness gap becomes harder to close. Digital transformation initiatives built on outdated data infrastructure are not transforming anything. They are building a digital facade over an analog foundation.
The risk of not replacing an aging historian is structural and compounding.
Every year the old system remains, the technical debt grows, the integration gap widens, and the AI readiness gap becomes harder to close. Digital transformation initiatives built on outdated data infrastructure are not transforming anything. They are building a digital facade over an analog foundation.
PART seven
Your 30-Day Evaluation Plan
From diagnosis to a deployment decision
action plan
Move from Decision to Deployment in 30 Days
Use this timeline to run a structured, low-risk evaluation that produces a defensible recommendation.
Conclusion
The Historian Decision Is a DX Foundational Choice
Digital transformation in manufacturing does not fail because the strategy is wrong. It fails because the data infrastructure cannot support it. The historian, the system at the center of your operational data architecture, is either an accelerator or a brake on everything your team is trying to build.
The five systemic failures documented in this guide are not hypothetical.
The five systemic failures documented in this guide are not hypothetical.
- They are the lived reality of Process Controls Engineers waiting 15 minutes for a trend during a live process upset, and Application Engineers maintaining 2 AM batch extracts because the API cannot handle concurrent queries.
- They are root causes that stay invisible because the historian silently discarded the 200 ms pressure spike before it was ever written to disk.
- They are DX roadmaps whose ROI calculations were quietly destroyed by per-tag licensing fees that were never on the original procurement spreadsheet.
- They are choosing what NOT to historize due to unnecessarily expensive tag licensing models.
The open source alternative is not a free option. Open source is the beginning of a product you must build, fund, and maintain internally, indefinitely. The decision looks different when the full scope of the build is on the table.
Timebase Historian was built to eliminate each of these failure modes: lossless data, native OPC UA and MQTT, active-active redundancy, open REST and WebSocket APIs, native MCP server for AI agents, Docker deployment, and a licensing model that ends the tag tax conversation permanently.
Timebase Historian was built to eliminate each of these failure modes: lossless data, native OPC UA and MQTT, active-active redundancy, open REST and WebSocket APIs, native MCP server for AI agents, Docker deployment, and a licensing model that ends the tag tax conversation permanently.
start your evaluation today
Zero Licensing Cost.
Full Capability. No Exceptions.
Download Timebase Historian and run it alongside your current system. No licensing conversations required.
FAQs
Why is Timebase Historian free?
Timebase Historian is free because Flow Software believes manufacturers should not be charged simply to store and access their own operational data. The company's business is focused on helping manufacturers create value from data, not restricting access to it.
Is Timebase Historian open source?
No. Timebase Historian is commercial software that is available at no cost. Manufacturers receive a professionally supported historian without tag limits, user limits, or licensing fees.
How is Timebase Historian different from a time-series database?
A time-series database stores data. Timebase Historian provides industrial data collection, store-and-forward, redundancy, security, APIs, visualization, and support for manufacturing protocols such as OPC UA, MQTT, and SparkplugB.
Is Timebase Historian built for AI?
Yes. Timebase Historian includes native MCP support, modern APIs, rich metadata, and AI-ready architecture designed to support AI agents and large language models.
Can Timebase Historian replace PI System, Canary Historian, AspenTech IP21, or others?
Timebase Historian can serve as an alternative for manufacturers seeking historian functionality, modern APIs, AI readiness, unlimited tags, and a no-cost licensing model. Flow Software produces additional calculation, event, and KPI tools that will enable you to build robust solutions that exceed the capability of PI AF, Canary Events and Calcs, or AspenTech solutions, without requiring historian standardization across every single plant.
How does Timebase Historian perform compared to the AVEVA PI System or the Canary Historian?
Timebase Historian provides the same level of logging robustness, redundancy, and security as AVEVA PI and Canary Historian. The Timebase Historian can write over 150,000 updates per second and can scale to over 1,000,000 tags per historian server. Most importantly, Timebase Historian exceeds AVEVA PI and Canary Labs at data retrieval by offering more flexibility with its MCP server, Websocket end point, and CESMII i3X API support.
Does the Timebase Historian work with Inductive Automation's Ignition?
Yes. Timebase Historian has a certified Ignition module that works with Ignition version 8.3+ to allow for Timebase Historian to be selected as both a Storage Provider and a Tag History Provider. This means you can use Ignition's naitive tag logging features as well as store and forward capabilities to write data to the Timebase Historian and you can read data from Timebase Historian directly from Perspective and Vision projects.
