Timebase Historian Vs. The Industry: 10 Features That Matter Most To Manufacturers

Free. Forever. No Exceptions.

A Feature-by-Feature Comparison for Engineers Who Are Done Paying a Historian Tax

The Historian Tax Is Officially Over

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.

The traditional historian vendors 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.

Enter Timebase Historian

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.

Feature 01: Licensing Model

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 the fine print — overage daily rates, PSA requirements for third-party applications, separately metered PI Integrators, per-named-user visualization licenses — 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 25-concurrent-API-client ceiling 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.

Feature 02: Data Integrity — Lossless Compression & Storage Fidelity

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.

Feature 03: Write Performance & Throughput

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, the High Performance Suite (which adds multi-archive distribution and auto-scaling) is the appropriate add-on. But at the base level, 150,000 writes per second covers the overwhelming majority of manufacturing deployments without additional investment.

Feature 04: OPC UA Native Data Collection

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

OPC UA is no longer the future of industrial connectivity — it is the present. 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 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.

Feature 05: MQTT & SparkplugB Support

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 MQTT 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.

Feature 06: REST API — Unrestricted Programmatic Access

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 — 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.

Feature 07: AI Agent Integration — Native MCP Server

Compared against: AVEVA PI System · GE Proficy Historian · InfluxDB 3.0

The Model Context Protocol (MCP) is an open standard developed by Anthropic that defines how AI models — large language models, AI agents, and AI assistants — 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 average temperature in Reactor 3 during the last production run?" or "Show me the pressure trend for the past eight hours on Line 2" or "Which tags exceeded their alarm limits in the past 24 hours?" — 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.

The significance of a native MCP server cannot be overstated for manufacturing organizations beginning to explore AI-driven operations. Without MCP, 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 (tag search, data retrieval, dataset browsing), and calls them directly using structured requests. The historian handles authentication, data retrieval, and response formatting. The AI agent gets clean, contextualized answers. Flow Software's AI Gateway add-on goes further: prebuilt tools with optimized short context windows specifically designed to make historian queries work reliably with the token budget constraints of production AI deployments.

Feature 08: High Availability — Active-Active Redundancy

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 — planned maintenance, hardware failure, network partition, 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: active-passive failover (one primary instance runs; a standby activates if the primary fails) and active-active redundancy (multiple instances run simultaneously, all receiving the same data stream). These are not equivalent. Active-passive failover has a failover gap — 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 resumes writing to both. The gap in historian A is covered by historian B — it is not recovered automatically, but the data exists. No data is lost at the operational level.

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.

Feature 09: Deployment Flexibility — Windows & Docker

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 not wrong — but it is 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.

Feature 10: WebSocket Event-Driven Data Delivery

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

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 three emerging manufacturing use cases. First, AI agent workflows: 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. Timebase's WebSocket connection enables this pattern natively. Second, digital twin synchronization: a digital twin model that mirrors the physical asset in real time needs value updates as fast as they arrive, not batched on a polling schedule. Third, real-time dashboards: browser-based visualization that shows live process values without page refresh depends on WebSocket push — it is the standard technology for live web data delivery.

Honeywell PHD's OPC DA subscription is conceptually equivalent — values are pushed on change — but the access protocol requires OPC DA client libraries, which modern web applications, AI frameworks, and cloud services do not natively implement. The value of a WebSocket interface is specifically that it is accessible from any modern application without specialized libraries.

The Case Is Clear. Start Storing Data Today.

Across ten features — the ten 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.