timebase historian vs.
the industry

If you have spent more than five minutes trying to justify a historian expansion to a finance team, you already know the feeling. You have data sitting in sensors, PLCs, and edge devices right now; data that could be driving better decisions, feeding AI agents, predicting failures, and improving throughput. But before any of that can happen, someone in procurement has to sign off on a tag count expansion, a new PSA license for the analytics tool your team wants to plug in, or an additional per-user fee for the visualization layer your operators need.

‍This is the historian tax. And manufacturers have been paying it, in one form or another, for thirty years.

Historian vendors like AVEVA PI, Canary, GE, and Siemens built their business models on scarcity. Every tag is a line item. Every programmatic access point requires a license. Every new application that wants to read your data has to pay a toll. The result is that operations teams make constant decisions about what not to historize, which tools not to connect, and which engineers not to give access to. Not because the data isn't worth having, but because the licensing model makes it too expensive to capture everything.

That model made sense when historians were exotic, expensive infrastructure. It makes no sense in 2026, when the value of operational data has never been higher, when AI agents are beginning to consume historian data directly, and when the cost of storage hardware has collapsed to the point where a terabyte costs less than lunch.

Timebase is a data historian built by process and control engineers. The Timebase development team is made of people who have spent decades on the plant floor watching good data go uncaptured because someone couldn't justify the licensing cost. The entire platform, including data collection, storage, trending, REST API access, WebSocket streaming, and security, is free. Not free-tier, not freemium, not free-until-you-scale. Free. Today. Tomorrow. Forever. No exceptions. There is no paid option for the Historian.

But here is the thing that makes Timebase worth talking about beyond the price: the architecture is legitimate. This is not open-source software bolted together with duct tape and shipped with a "you get what you pay for" disclaimer. Timebase runs a purpose-built NoSQL binary columnar storage engine, tested continuously at over one million tags. It writes at 150,000 values per second per dataset. It performs lossless compression, meaning every data point you store is the data point you get back (no swinging-door approximations), no tolerance-band losses, no values silently discarded in the name of storage efficiency. It deploys on Windows or as Docker containers. It runs multiple historian instances simultaneously with active-active redundancy. And it ships with a native Model Context Protocol (MCP) server, making it the only historian on the market that an AI agent can connect to out of the box, today, without middleware.

The ten features that follow are the ones that matter most in a real manufacturing environment. For each one, Timebase is the benchmark. Three competitors join the comparison for each feature, selected because they represent the realistic alternatives that engineers evaluate. The comparison is direct, the differences are real, and the conclusion is consistent: you do not have to pay a historian tax to have a world-class historian.

Compared against: AVEVA PI System · Canary Labs · GE Proficy Historian

Ask any engineer who has managed a historian deployment what keeps them up at night, and licensing is almost always in the top three. Tag count limits create operational anxiety. Per-consumer access licenses turn every new analytics tool into a budget conversation. And beware the fine print... overage daily rates, PSA requirements for third-party applications, separately metered PI Integrators, per-named-user visualization licenses; these all can make an already expensive system genuinely unpredictable at scale.

The AVEVA PI licensing model is the most complex in the industry. Manufacturers running AVEVA PI with ten third-party applications consuming data; analytics platforms, AI tools, Power BI integrators, Seeq, custom Python pipelines, etc. are paying for each of those connections through PSA licensing stacked on top of their tag-count subscription. When an engineer wants to connect a new tool, the first question is not "will this work?", it is "what will this cost?".

Canary Labs introduced meaningful pricing transparency to the historian market in 2017 with an Unlimited tier that was clearly priced and deserves credit for what it did to bring transparency in pricing to manufacturing. However, in recent years, their pricing model has changed, and most would say it has not changed for the better. Still, today, when compared to AVEVA PI's cost, Canary is a real alternative for organizations that have tag-count budget constraints but are determined not to embrace a fully free model. No longer knowing what an Unlimited tier costs, or the out-of-the-box limit of 25 concurrent API clients on the standard Views license is the constraint most likely to create friction as AI agent deployments scale.

GE Proficy's consumption pricing on AWS Marketplace is the most commercially innovative model among the traditional historians. For cloud-native deployments, pay-as-you-go removes capital risk. But "more flexible" and "free" are categorically different propositions. Every tag, every query, every month still costs something, and as we have all learned, cloud storage, compute, and query fees can add up very quickly.

Compared against: AVEVA PI System · GE Proficy Historian · Honeywell Uniformance PHD

Every data historian compresses data. The question that most manufacturers never think to ask is: what kind of compression, and what gets thrown away?

Swinging-door compression (the algorithm used by AVEVA PI, GE Proficy, Honeywell PHD, and AspenTech IP.21) works by examining incoming values against a tolerance corridor. If a new sample falls within the slope range defined by the last two stored points, it is discarded. The stored archive contains a mathematically reconstructed approximation of reality, not the actual measurements from the field. For smooth, slowly changing process variables, this loss is often below engineering significance. For instrumentation with noise, for fast-changing variables, or for any application where the raw sample is the legally required artifact, it is not.

The practical impact of lossy compression is most visible in three manufacturing scenarios. First, in regulated environments such as pharmaceutical, food and beverage, nuclear, or medical device production, where the raw sample from the field instrument is the auditable artifact. A value reconstructed by swinging-door interpolation is not the value the sensor reported. Regulatory agencies increasingly understand this distinction. Second, in high-frequency applications like vibration monitoring, motor current signature analysis, fast-loop PID diagnostics, etc. where the compressed archive may be missing the exact sample that contains the fault signature. Third, in AI and machine learning applications, where training data quality directly determines model quality: a training set composed of lossy-compressed historian data produces models trained on approximations, not ground truth.

Compared against: GE Proficy Historian · AspenTech InfoPlus.21 · InfluxDB 3.0

Write throughput is the fundamental performance constraint of a historian. When a historian cannot ingest data faster than it arrives, samples are queued, dropped, or averaged, all of which degrade data quality. For manufacturers running high-density sensor networks, high-speed machines, or enterprise-wide aggregation across many sites, write performance is not a theoretical concern. It is a design constraint.

Timebase and GE Proficy are benchmarked at the same headline write rate — 150,000 values per second, but the architectural basis differs meaningfully. GE's figure represents the collector-to-server pipeline; Timebase's 150,000 writes-per-second figure is the Dataset-level write rate of the historian server itself, tested continuously under production-like conditions.

Timebase's hourly file segmentation means write operations are always appending to the current hour's binary file: no index rebalancing, no lock contention, no fragmentation accumulating over time.

IP.21's RAM dependency is its primary write throughput limiter in high-tag-count deployments. When the in-memory snapshot database approaches the server's physical RAM limit, write performance degrades in ways that are difficult to predict and require hardware upgrades rather than configuration changes.

InfluxDB 3.0 genuinely outperforms Timebase on raw write throughput for bulk historical ingest via Arrow Flight — this is worth acknowledging directly. InfluxDB's columnar architecture and Arrow Flight binary protocol are engineering achievements. For Timebase deployments requiring ultra-high-frequency ingest at massive scale, scaling with additional historian servers is the appropriate architecture. But at the base level, 150,000 writes per second covers the overwhelming majority of manufacturing deployments without additional investment.

Compared against: AVEVA PI System · Honeywell Uniformance PHD · Inductive Automation Ignition

OPC UA is the standard for industrial connectivity. Every major PLC, DCS, SCADA, and edge gateway released in the last decade speaks OPC UA. The ISA-95 and ISA-88 working groups have formalized OPC UA companion specifications for manufacturing operations, robotics, batch control, and process equipment. For any historian evaluating new installations or greenfield deployments, the quality of the OPC UA implementation is the primary collection architecture question.

Timebase's OPC UA collector operates on a subscription model, not a poll model. This is not a minor implementation detail. Polling-based collection burns server-side OPC UA subscription capacity, introduces artificial sampling latency (a tag that changes at 100 ms resolution but is polled at 1,000 ms intervals loses 90% of its data), and creates unnecessary network load. Subscription-based collection means the OPC UA server at the source notifies the collector on change — the data arrives at the historian when it changes, not when the collector next asks.

The Ignition-Timebase relationship deserves particular attention. Ignition is built on OPC UA and offers a built-in OPC UA server that makes the entire platform easy to work with. Better yet, Ignition 8.3 introduced a native Timebase connector that streams tag history directly from Ignition into Timebase without a separate Collector instance. For the rapidly growing segment of the market that has standardized on Ignition as its SCADA and edge platform, this means Timebase slots in as the dedicated historian layer, getting the unlimited tag storage and AI-ready APIs of Timebase alongside the device driver breadth and SCADA capability of Ignition. These two free-to-low-cost platforms together cover the full OT stack for a fraction of what a traditional SCADA plus historian bundle costs.

The AVEVA (formerly OSIsoft) PI integration for OPC UA fully supports report-by-exception subscription mechanisms. However, despite this native capability, users frequently report reliability and performance bottlenecks, particularly when pushing large scales of high-frequency data into the PI Data Archive. Users compliants center on administrative tasks like renaming tags within the connector architecture remain rigid and can lead to immediate data loss. While modern AVEVA Adapters offer structured polling fallbacks via explicit schedule configurations, the architectural friction between edge data ingestion and central server performance remains a key challenge for many deployments.

Organizations with larger Honeywell Uniformance PHD deployments have reported operational challenges around reliability and administration. As systems grow, communication interfaces can become resource intensive, even leading to stalled data collection, buffering issues, or gaps in historical records if problems are not detected quickly. Configuration can also be more involved than many modern historian platforms, relying on Windows Registry settings, security certificate management, and other manual administrative tasks that can be difficult to troubleshoot when environments change. The result is a platform that is capable of collecting industrial data effectively but may require a higher level of ongoing engineering effort to maintain stable communications and ensure consistent data collection across large, complex manufacturing environments.

Compared against: AVEVA PI System · GE Proficy Historian · AspenTech InfoPlus.21

MQTT is the dominant messaging protocol for IIoT edge devices and cloud-to-plant integration. Its publish-subscribe architecture, lightweight footprint, and broker-based decoupling make it ideal for distributed manufacturing environments where devices, machines, and cloud services all need to exchange operational data without tight coupling. SparkplugB extends MQTT with a structured, typed, stateful payload specification designed specifically for industrial data — solving the semantic ambiguity problems that plain MQTT introduces when payloads are arbitrary JSON or binary strings.

Organizations deploying Unified Namespace (UNS) architectures, where a central broker serves as the semantic backbone of the manufacturing data infrastructure, need their historian to be a native citizen of that broker network, not a peripheral system connected through middleware.

The distinction between a generic MQTT collector and a native SparkplugB collector is more significant than it might appear. Standard MQTT payloads carry no embedded type information, no equipment state context, and no guaranteed message ordering semantics. A historian receiving raw MQTT must be configured with payload parsing rules for every topic; and those rules must be updated whenever the publisher changes its schema. SparkplugB solves this with a self-describing payload format: every metric has a typed name, a timestamp, a quality indicator, and a device state context. A native SparkplugB historian collector can automatically configure tags from Birth certificate messages, handle device rebirths gracefully, and correctly interpret null values and stale data conditions without custom parsing logic.

As UNS adoption accelerates across manufacturing (driven by the ISA-95 Part 6 data operations model and the growing ecosystem of SparkplugB-compatible edge devices) the historians that natively speak SparkplugB will have a structural advantage in new deployments over those that require middleware translation.

AVEVA PI offers a PI Connector for MQTT Sparkplug, which acts as an MQTT client and retrieves data from MQTT servers that follow the Sparkplug specification. User feedback around modern PI connectivity has been mixed, with some users describing AVEVA’s newer adapters as limited compared with older PI Interfaces and competing platforms. One public forum comment specifically calls AVEVA’s modern connectivity products “lackluster” and notes that many legacy PI Interfaces are not compatible with newer AVEVA architectures.

GE Proficy Historian also supports MQTT and Sparkplug B and can collect the data, but the public documentation does not clearly show the same level of automatic asset, relationship, and measurement discovery described in AVEVA’s Sparkplug connector documentation.

AspenTech InfoPlus.21 is weakest in MQTT and Sparkplug B positioning without any clear indications that  IP.21 can participate in MQTT-based architectures without requiring middleware and additional integration layers, third-party connectors, etc. MQTT and Sparkplug B do not appear to be first-class historian ingestion patterns for IP.21.

Timebase Historian is different. MQTT and Sparkplug B are not treated as edge cases or external integration projects. They are part of the core historian strategy. Timebase is designed for modern industrial architectures where data is expected to move through various vanilla MQTT payloads and Sparkplug B. The goal is not merely to collect values from MQTT topics. The goal is to make operational data easier to discover, query, contextualize, and use across humans, applications, and AI agents. That matters because digital transformation is no longer just about logging tags. It is about creating an architecture where data carries enough context to support analytics, AI, knowledge modeling, and enterprise integration.

Legacy historians can often ingest MQTT data. The better question is whether they can preserve enough meaning to support what comes next.

Compared against: AVEVA PI System · Honeywell Uniformance PHD · Canary Labs

The REST API is the integration surface of the modern historian. Every analytics platform, every AI tool, every custom dashboard, every data pipeline, and every business intelligence application connects to historian data through an API. The technical quality and the commercial terms of that API are therefore not secondary considerations, rather they are the primary determinant of how useful the historian actually is in a connected manufacturing environment.

The PI Web API is technically well-engineered, it covers tag search, time-series retrieval (raw, interpolated, aggregated, plot-compressed), event frame creation, and AF hierarchy traversal. The problem is not the API itself. The problem is the PSA licensing model that surrounds it. When an organization has ten third-party applications consuming PI data, they are paying PSA licensing for each. When they deploy an AI pilot that requires a new programmatic connection, the first conversation is about PSA costs, not about the technical integration. When a developer wants to test a new analytics approach with a weekend project, they need a licensed access credential before they can start.

Honeywell PHD's absence of a REST API is not a historical oversight that will be corrected in the next release — it reflects a fundamental architectural orientation toward OPC as the integration standard. For manufacturing environments building on modern integration patterns (REST, webhook, event-driven APIs), PHD requires a middleware bridge that adds latency, maintenance burden, and a new failure point.

Canary Labs Historian provides a free REST API for both raw and aggregated data access, they have led the industry for a decade in data accessibility. Out-of-the-box, the API is only licensed for 25 concurrent users, a concern if Canary begins to charge for additional connectivity but so far has not, they will license additional users upon request.

Timebase Historian embraces the philosophy that manufacturers should never be constrained by proprietary APIs. Every piece of operational data should be accessible using modern, well-documented interfaces that make it easy for applications, analytics platforms, enterprise systems, and AI agents to interact with historical information. Rather than forcing developers to learn proprietary SDKs or vendor-specific programming models, Timebase exposes its data through a comprehensive REST API that provides secure, standards-based access to historical values, current values, metadata, and historian capabilities.

Timebase is also the first adopter of CESMII's Industrial Information Interoperability eXchange (i3X), an open, vendor-agnostic API initiative designed to eliminate "API chaos" across manufacturing software platforms. Instead of every historian, MES, quality system, and manufacturing application exposing its own unique interface, i3X establishes a common API for discovering assets, navigating relationships, querying current and historical values, updating information where permitted, and subscribing to change events. The result is dramatically improved application portability, reduced integration effort, and a common foundation for AI-ready manufacturing architectures.

Compared against: AVEVA PI System · AspenTech InfoPlus.21 · Canary Labs

The Model Context Protocol (MCP) is an open standard developed by Anthropic that defines how AI models connect to external tools and data sources. Just as OPC UA standardized device-to-SCADA communication and REST standardized service-to-service communication, MCP is standardizing AI-to-data-source communication.

An AI agent with access to an MCP-compatible historian can answer questions like "What was the worst data quality in Reactor 3 during the last production run?" or "Show me any pumps that have stale data" or "Which tags exceeded their alarm limits in the past 24 hours?". All of this without a human analyst pulling the data, without a custom integration, and without a developer building a purpose-specific tool. This is not a future capability. It is available today, for any manufacturer willing to connect the right historian.

But MCP alone is not enough. For the agents to return trustworthy information, tools (or skills) need to be provided alongside the MCP access point so the agent will understand how to interact with the historian. Without MCP and the proper tools, connecting an AI agent to a historian requires: authenticating the agent to the historian's API, writing tool-calling wrappers that map agent intent to API calls, managing context window size to stay within LLM token limits, and handling time-series data formats that LLMs are not natively trained to interpret.

Timebase's MCP server handles all of this within the historian process. The AI agent connects to the MCP endpoint, discovers the available tools (over a dozen unique tools), and calls them directly using structured requests. The historian handles authentication, data retrieval, and response formatting. The AI agent gets clean, contextualized answers.

While platforms such as AVEVA PI System, Canary Historian, and AspenTech InfoPlus.21 can expose historian data to AI agents through REST APIs, SDKs, or custom middleware, they all rely on separate MCP server implementations or custom translation layers to bridge the gap between proprietary historian interfaces and the open MCP standard. This adds architectural complexity, increases deployment effort, and creates another component (AI tools) that must be built, secured, and maintained.

Compared against: AVEVA PI System · Canary Labs · Inductive Automation Ignition

Historian downtime has a cost that is easy to underestimate until it happens. When a historian goes offline for planned maintenance, hardware failure, network partition, or a software crash, the data that would have been collected during that window is gone. Processes that ran, events that occurred, and anomalies that happened during the outage exist only in the memory of whoever was watching the control screens.
‍
The historian's job is to make sure that never happens. High availability architectures fall into two broad categories, and these are not equivalent. :
Active-passive failover: one primary instance runs; a standby activates if the primary fails
Active-active redundancy: multiple instances run simultaneously, all receiving the same data stream

Active-passive failover has a failover gap. The gap is the time between the primary failing and the standby activating, during which data may be queued, buffered, or lost. Active-active has no failover gap, because there is no failover.

The operational simplicity of Timebase's active-active approach is worth emphasizing. A logging session is configured once, targeting two historian IP addresses. From that point forward, both historians are identical mirrors of the live data stream. No cluster management software. No replication monitoring. No split-brain resolution protocol. No switchover procedure. If historian A goes offline, historian B continues as if nothing happened. When historian A comes back online, the collector (which features store and forward buffering) pushes the stored values to the previously offline historian and resumes the current logging of data, all without a gap in the history.

AVEVA PI Collective achieves comparable active-active semantics at the storage tier, but it is a significantly more complex deployment. Collective members must be sized identically, are not usable independently, and require AVEVA-specific expertise to manage. Timebase's redundancy model is within reach of any operations engineer.

Canary Labs provides the same model as Timebase, focused on true redundancy with store and forward buffering and automatic recovery. Together Timebase and Canary are the standard.

Ignition 8.3 operates on a strictly active-passive (Master-Backup) architecture for its core gateway redundancy system. Only the active Master node logs data under normal operation, while the standby Backup node utilizes store-and-forward local caching or full-mode failover logging to prevent data loss during a network split.

Compared against: AspenTech InfoPlus.21 · Honeywell Uniformance PHD · AVEVA PI System

The industrial software market has historically been Windows-centric, and for good reason, the majority of OT infrastructure runs on Windows, plant networks are often managed by IT teams with Windows expertise, and DCS vendors certify their interfaces against specific Windows versions. But manufacturing environments are diversifying rapidly. Edge compute devices run Linux. Cloud deployments run Linux containers. DevOps teams expect Docker. Security-conscious IT teams want to run OT software in isolated containers with defined resource limits and easy rollback via image versioning.

A historian that runs only on Windows is now a constraint. A historian that runs on both Windows and Linux via Docker containers is a platform decision that respects where manufacturing IT is heading. The Docker deployment path is not just about containers for its own sake. Docker brings concrete operational benefits that matter in a manufacturing environment. Deployment is reproducible, the same Docker image deployed to a test server and a production server produces identical behavior, eliminating the "it works in my environment" class of problems. Updates are atomic, rolling back to a previous version is a docker pull and a container restart, not a Windows installer rollback with registry cleanup. Resource limits are explicit, the historian container can be constrained to specific CPU and memory allocations, preventing it from competing with other processes on shared hardware. And security isolation is improved, the historian process runs in a namespace with only the permissions it needs.

For manufacturers deploying at the edge (on factory floor servers that need to run multiple applications on shared hardware) the container model is increasingly standard. Timebase's Docker support means the historian deploys on the same edge hardware and with the same operational tooling as the rest of the edge software stack.

You cannot deploy AVEVA PI, Honewell PHD, or AspenTech IP21 in containerized environments, they all require multiple Windows environments, often in the case of AVEVA this means more than 10 different Windows servers.

Compared against: AVEVA PI System & Canary Labs

Most historian integrations today are built on a polling model: a downstream application calls the historian API on a schedule, retrieves data since the last call, and processes it. Polling works. It is also wasteful, introduces inherent latency proportional to the polling interval, and creates a data delivery pattern that is fundamentally incompatible with event-driven architectures.

Consider the difference in practice. A machine learning inference pipeline that monitors a specific process variable for anomaly detection needs to react to value changes in near real-time. On a polling model, it calls the historian every five seconds, discovers a change, and processes it with up to five seconds of guaranteed latency baked into every detection cycle. On an event-driven model, the historian notifies the pipeline the moment the value changes, latency is milliseconds, not seconds, and no API calls are wasted when values are not changing.

The WebSocket access model matters most in modern use cases. For instance when an AI agent is monitoring a process and needs to respond to a specific condition (a temperature threshold, a machine state transition, a quality deviation) it should not be polling. It should subscribe to the relevant tags and receive a notification the moment the condition occurs.

Here Timebase, Canary, and AVEVA PI all deliver, each featuring a WebSocket connection. Of course, like most things, you will pay a penalty for AVEVA licensing, Timebase and Canary Historian provides the WebSocket endpoint for free.

Across the ten features that matter most to manufacturers making real deployment decisions, Timebase Historian either leads the field or matches the best available alternative. Not as a budget option. Not as a stepping stone to something better later.

As the technically correct choice for modern manufacturing data infrastructure, delivered at a price that removes every financial barrier to getting started.

The free price tag is not the headline. The headline is what the free price tag enables: engineers who historize everything without asking permission, analytics teams who connect every tool without budget approval, AI agents who access operational data without middleware, and operations leaders who finally get the data foundation they were always promised and never fully received.

Free Today. Free Tomorrow. Free Forever. No Exceptions.